Hi, And thanks for the prompt reply!
I prefer the AppAuth pattern where the native app is a OAuth client to your server and you are protecting your API with OAuth. Your AS becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and uses federated or local authentication to issue tokens. (this gives your backend API access to user info)
I'm not sure I followed due to the use of non-standard terminology... What do you mean by "OAuth client" - the Relying Party? And what about AS? Is that the Authorization Server, Application Server, or what? (One of the frustrating aspects of learning about OAuth2 and OIDC is that not everyone uses the standard terminology.)
The other pattern is for the native app to be a Connect client to Google or other IdP and then passes a id_token (not access token) to your backend in some secure manor and your backend validates the signature on the id_token and that it was issued to your client (verification is essential) (the native app gets access to user info api) You still have the problem of how you secure your API, as you need to exchange the validated id_token with something. I thnk that doing this securely winds up being more complicated than the first option.
The same problem as above. I cannot find "Connect client" anywhere on the OIDC terminology. And is IdP what the standard calls OP? I don't mean to sound ungrateful, but when a newcomer asks a basic question is usually a bad idea to throw a lot of jargon or non standard terminology at them... Best regards, Dario Teixeira _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
