Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
A mobile app that just used Google API only would/should register for a Google client Id and use connect with Google. A mobile app that uses only its own API should have a client ID from its own authorization server, and leave it to the authorization server to deal with the authentication. Where it gets more grey is when the native app wants to access both Google API directly and its own REST API. In the simple AppAuth model you could have the App owners Resource server proxy the information from Google etc as it gets a google access token if the user authenticates to google via Connect. I think that is the safest way to do it. Justin’s recommendation is a bit more optimised for this scenario where the Native application wants to access two resource servers. In that case with one client_id from Google it can get both a id_token and access token for Google. It uses the acess token to get the plus friends list or something like that and sends the id_token to its backend to exchange for a cookie or some other form of access token assuming the Native apps authorization/resource server doing the exchange properly validates the signature and audience in the id_token. The original question was not about multiple RS and I don’t think that is really the most common case, so I didn’t go there in my answer as it adds more complexity to something that is complex enough. John B. Sent from Mail for Windows 10 From: Phil Hunt (IDM) Sent: January 27, 2017 5: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 the branding experience much has been done in silo approaches of the past. Adding to the confusion I note that many of the cloud provider site docs do not clearly distinguish mobile apps from web apps. Mobile app developers arw reading docs and telling me that oracle, google, and azure require the mobile app to register for an openid client id. Near as I can tell it is confusion over the difference between authz and authN. Phil On Jan 27, 2017, at 5:23 PM, ve7...@ve7jtb.com wrote: It sounds like you are currently doing something like the OAuth resource owner flow. Is there a Authorization server currently associated with your resource server? If so you can change the OAuth flow you are using to the code one as described in App Auth. You still need to authenticate the users at your server using the current username and password or via OpenID Connect to Google. This is a two step process. If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc. OAuth from the NA to your server to authorize the native app, and your server 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: [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 looking for, though there is a chance there is some misunderstanding about the whole picture. Allow me to summarise the current situation: Users interact with a Native App (NA) running on a mobile phone. This app talks with a Resource Server (RS) via a RESTful API. Because there is private user data on the RS, the very first interaction between the NA and the RS is a login where the NA asks the user for an email+password combination, which it then sends to the RS. If the email+password combination is valid, the RS replies with an access token that must be used by the NA in all its future requests. This works fine, but has the disadvantage of requiring users to manually enter their email and password. The user experience would be much improved if users had the option to login using their Google, Facebook, or Github account. Now, it is my understanding that OpenID Connect is the technology used nowadays to provide this sort of Single Sign-On. All I'm looking for is documentation on how OIDC is actually implemented in this scenario. Best regards, Dario Teixeira smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
It sounds like you are currently doing something like the OAuth resource owner flow. Is there a Authorization server currently associated with your resource server? If so you can change the OAuth flow you are using to the code one as described in App Auth. You still need to authenticate the users at your server using the current username and password or via OpenID Connect to Google. This is a two step process. If you try to combine them by trying to make your NA the connect client you may save a step in the short term but will regret it in the long term when you decide to add another identity provider like Microsoft etc. OAuth from the NA to your server to authorize the native app, and your server 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: [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 looking for, though there is a chance there is some misunderstanding about the whole picture. Allow me to summarise the current situation: Users interact with a Native App (NA) running on a mobile phone. This app talks with a Resource Server (RS) via a RESTful API. Because there is private user data on the RS, the very first interaction between the NA and the RS is a login where the NA asks the user for an email+password combination, which it then sends to the RS. If the email+password combination is valid, the RS replies with an access token that must be used by the NA in all its future requests. This works fine, but has the disadvantage of requiring users to manually enter their email and password. The user experience would be much improved if users had the option to login using their Google, Facebook, or Github account. Now, it is my understanding that OpenID Connect is the technology used nowadays to provide this sort of Single Sign-On. All I'm looking for is documentation on how OIDC is actually implemented in this scenario. Best regards, Dario Teixeira smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app
Unfortunately RFC 6749 lacks a terminology section. >From Connect we have >http://openid.net/specs/openid-connect-core-1_0.html#Terminology (AS) is a common abbreviation for Authorization server. In sec 1.1 of OAuth https://tools.ietf.org/html/rfc6749#section-1.1 Roles are defined Client and authorization server. Given that we have two sorts of clients one as defined by OAuth that is doing authorization only and one using the Connect extensions that is additionally doing Authentication I refer to them as OAuth client and Connect client. A connect client being a OAuth client using the Connect extensions for authentication (id_token etc). The connect spec calls it a client and as it is the connect spec the connect part is implied. OpenID Provider (OP) is a term going back to OpenID 1. Generic identity standards like SP-800-63-3 https://pages.nist.gov/800-63-3/sp800-63-3.html#sec3 Use the term Identity Providers (IdP) to refer to servers providing federated identity using any protocol. (Note to NIST the term Identity provider is used but not defined in terms. Probably obvious to the authors, but not neccicarily to the reader My point being that twitter, facebook and some others do not do OpenID Connect so are not technically OP. I could use relying while in the middle of a Fido meeting as a excuse but everyone knows that even if I had taken the time it would have come out about the same. Hope that helps. John B. Sent from Mail for Windows 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 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 smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Recommendations for browser-based apps
It depends on what you mean by browser based apps. In general for single page apps that are java script executing in the browser dom, the recommendation would be implicit flow. These apps don’t by definition need offline access as they go away when the user is not present. We have talked about developing guidance for single page apps, but don’t have anything yet. I think it needs to be thought through again now that new things like service workers are available, and we will eventually get token binding in the browser (hint it is on in IE and Edge on windows 10 preview and in Chrome behind a feature flag now) You could use the PKCE appAuth type flow in a SPA app if you have the correct CORS setup. I however cant at this point say that you are getting improved security for the extra work in that environment. John B. Sent from Mail for Windows 10 From: Aaron Parecki Sent: January 25, 2017 3:12 PM To: OAuth WG Subject: [OAUTH-WG] Recommendations for browser-based apps Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have a solid recommendation for how to do OAuth 2.0 for native apps. Given that PKCE is intended for "public clients" and not specifically native apps, I'm wondering where that leaves browser-based apps. The core spec still says that the implicit grant is recommended for browser-based apps, but it's looking like the recommendation is to use the authorization code flow + PKCE with no secret for browser-based apps. Am I correct in thinking that the general recommendation would be to use the authorization code flow with no secret, and even better to use PKCE for browser-based apps? Aaron Parecki aaronparecki.com smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 issue tokens. (this gives your backend API access to user info) 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. There are other options that may not be allowed by the IdP where your backend is the Connect client and has a client secret. The mobile app makes the request and gets the code back. It then sends code and pkce verifier to it’s backend and the server exchanges it with it’s secret to get a id_token and access token. You still need to add security for your API. (custom scheme redirects for confidential clients may not be allowed depending on the Connect IdP) I think the first option is the best design that gives the best long term design as new IdP can be added without changing the deployed app. John B. Sent from Mail for Windows 10 From: Dario Teixeira Sent: January 25, 2017 7:59 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, I am building a mobile app and a server. The mobile app fetches user-specific data from the server, and therefore some sort of authentication is required. I would like to avoid the traditional username+password scheme, and instead allow users to login via Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) is the recommended solution nowadays, so my question is about the usage of OAuth2/OIDC in this scenario. All OIDC docs and tutorials describe the interaction between three parties: a Relying Party (RP), a User Agent (UA), and an OIDC Provider (OIP). There are however four parties in my scenario: the mobile app, the server, the UA, and the OIP. Which should take the role of RP? I see two different ways to do this: 1) The mobile app is the RP. It even takes care of starting a small web server to receive the data from the OIP. At the end of the interaction, the mobile app has a JWT signed by the OIP, which it sends to the server, which must validate it using a built-in list of OIP public signatures. 2) The server is the RP. When the user wishes to login, the mobile app asks the server about the OIP's authorization endpoint. The server provide the client with an URI whose redirect_uri parameter points to the server. All subsequent steps are handled by the server. Anyway, this seems like a fairly common scenario, and I would rather follow some best-practices documentation instead of cooking up my own schemes, like points 1 and 2 above. Therefore, if there is indeed such documentation, could someone please point me towards it? And if not, which would be the recommended route, 1 or 2? Thanks in advance for your attention! Best regards, Dario Teixeira ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth smime.p7s Description: S/MIME Cryptographic Signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 for Native Apps: IPR Confirmation
I know of no IPR disclosures for this document. I have none to make. John B. Sent from Mail for Windows 10 From: Hannes Tschofenig___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] URGENT: WPAD attack exposes URL contents even overHTTPS
PS Using PKCE S256 would prevent this attack on web server clients, as long as the client uses a different PKCE vale for each request.Even if the attacker can observe both the request and response, they would not have the code_verifyer and if replaying the code to the client the client will use the wrong verifier value to exchange the code and will get an error. That is probably the simplest mitigation against this for the code flow on web servers and native apps. I will think about it overnight. John B. Sent from Mail for Windows 10 From: ve7...@ve7jtb.com___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
