Afaik, the client app ends up with an access token (at). It never has to deal with id tokens. That all happens by way of the oauth AS server calling oidc itself. Iow the oauth as is the oidc client.
The code in the mobile client is trivial by comparison and does not need to do id token validation. Phil > On Jan 26, 2017, at 8:51 AM, Dario Teixeira <dario.teixe...@nleyten.com> > wrote: > > Hi, > >> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2] >> They are OpenID foundation library's not Google's. Google, Ping and >> a number of others are active contributors if you look at the git >> repositories. > > Thanks for the link. Perhaps I'm missing something, but the AppAuth > pattern as described by this document represents only half the picture: > at the end of the interaction, the native app is in possession of a > token that authenticates the user. However, my server cannot accept > that token blindly! > > Now, the way I would solve this is by keeping a hard-coded list of > OpenID Provider public keys on my server, which I would use to > verify that the token was indeed signed by the OIP. Correct me > if I'm wrong, but this also seems to be the recommended approach, > right? > > Thanks again for your time! > Best regards, > Dario Teixeira > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
