Cross-Origin-Authentication with AccessToken for SSO-Usage

[padLuk]

Hi, over the last days I tried figuring out what's the best way of doing SSO between a mobile native app and a web app. The mobile app is secured with 'resource owner password credentials'-flow and has its own login form.

Our requirement is that the user is able to jump from the native app into other client applications also secured with the same IdP. The other client applications are web applications that should be displayed in In-App-WebViews or maybe Custom-Tabs.

So I found your draft for the Cross-Origin-Authentication and thought it was quite suitable for our use case.

Do you see any problems of doing something similar by sending the Access-Token to the Cross-Origin-Authentication-Endpoint? I know it's not the best way of giving the Access-Token to the useragent but the native app is a confidential client application.

Thanks for some hints or opinions from your side.

[twistedstream]

@padLuk I just stumbled across your question and had a few thoughts. I'm not the author of this spec, so I'm not responding on their behalf. These are just my own opinions:

• As you may know, the only truly secure way to enable SSO between two applications is with redirect-based flows. With OAuth 2.0, this would either be using Authorization Code Grant or Implicit Grant, both which allow a cookie to be set on the Authorization Server, which is the basis for SSO between useragents. This, of course, cannot be done when the client makes direct API calls to the Authorization Server, as with Resource Owner Password Grant.

• Mobile applications have historically used ROPG for username/password authentication (supposedly for UX reasons), but the industry is now moving away from this. One of the reasons is for its lack of support for SSO. But it also less secure, promoting phishing apps. It's also less flexible since it really only supports one type of authentication (eg. social authentication, like with Google, requires the browser). The more secure, more flexible alternative for mobile is to use Authorization Code Grant + PKCE, which is detailed in RFC 8252. Mobile OSs have also embraced this approach and make the (embedded browser) UX much better. In fact, if you look at how Google does authentication for all of their first-party apps (Gmail, Drive, YouTube, etc), you'll see they use this approach.

• AFAIK, there's no such thing as a native app that's a "confidential client". Per the OAuth 2.0 spec, confidential clients are:

  Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

  In other words, only server-based applications can be considered confidential since they can store secrets (eg. client_secret). Alternatively, a native application is considered a "public client" since it can't securely store the secretes necessary to securely authenticate itself to the Authorization Server.

If you already have an OAuth 2.0 Authorization Server, I highly suggest you look into using ACG+PKCE for your mobile application. Since you'll be using the system browser for authorization, SSO will work "out of the box" should you want to send the user to a web page hosted at the same domain. If your server does not support this, then I encourage you to maybe look for alternative ones that do. I found several good options when Googling authorization code grant pkce sso.