Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

:45 PM To: ve7...@ve7jtb.com Cc: Dario Teixeira; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app What is concerning is that many are using resource owner flow so the client app can capture the uid/password under the assumption that the client needs to control

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

> to Google via Connect to Authenticate the user. > > Regards > John B. > > > > > Sent from Mail for Windows 10 > > From: Dario Teixeira > Sent: January 27, 2017 9:16 AM > To: John Bradley > Cc: Phil Hunt; IETF oauth WG > Subject: Re:

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

: Phil Hunt; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, Thanks for your reply and your patience! > Our recommendations are based on the assumption that the end state > is your app having an access token for your rest API. > If that is not what you a

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

Hi, Thanks for your reply and your patience! Our recommendations are based on the assumption that the end state is your app having an access token for your rest API. If that is not what you are trying to do then we may be talking at cross purposes. Yes, that is exactly the end state I'm

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

If you are protecting your API with OAuth in my recommendation there are two Authorization and token endpoints. One set run by Google (as an example) for authentication and issuing a access token for the Google User_info endpoint, and one set run by you to issue a access token for your resource

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

An seeing bad impls with justins pattern. In particular aud is not checked. The idp has to know the rsrc aud or the as has to know the client id the mobile app is using with OP provider. It ends up being complex with room for mistakes. Phil > On Jan 26, 2017, at 10:00 AM, John Bradley

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

Justin and I are recommending different approaches. My recommendation is that your app do appAuth to your server to get a access token for your API. Your server performs openid connect to google, SAML to salesForce or Facebook Connect to Facebook and manages verification keys. If the user is

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

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

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

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

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

https://tools.ietf.org/html/draft-ietf-oauth-native-apps 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. John B. On Jan 26, 2017 7:13 AM, "Dario Teixeira" wrote: >

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

ows 10 From: Dario Teixeira Sent: January 26, 2017 7:03 AM To: ve7...@ve7jtb.com Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, And thanks for the prompt reply! > I prefer the AppAuth pattern where the native app is a OAuth client to > your se

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

Hi, +1 to AppAuth One disturbing pattern I see for mobile apps relaying the idtoken is that the aud isn't checked by the AS in the Oauth exchange. This in part caused by the fact that the mobile app has two client-id identifiers. If the aud only has the clientid for the OIDC call this can be a

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

Hi, 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

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

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

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

+1 to AppAuth One disturbing pattern I see for mobile apps relaying the idtoken is that the aud isn't checked by the AS in the Oauth exchange. This in part caused by the fact that the mobile app has two client-id identifiers. If the aud only has the clientid for the OIDC call this can be a

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

+1 to the AppAuth pattern On Wed, Jan 25, 2017 at 12:48 PM, wrote: > There are a number of patterns that people use. > > > > 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 >

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

There are a number of patterns that people use. 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

Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

I would recommend making the mobile app the RP, and having the server be an additional protected resource that accepts access tokens from the mobile app. This is how it's commonly handled, and there are libraries (such as Google's AppAuth) that handle most of these interactions. -- Justin