Search code examples
authenticationsingle-sign-onopenidopenid-connect

Is this the proper use of OpenID Connect for this use case?

I'm trying to understand how to use OpenId Connect in the following use case. Let's say we just have the following 3 components:

  • Web app with an exposed API (Service Provider aka SP).
  • A separate authentication server (Identify Provider aka IDP) used for SSO with the above SP.
  • A native client app used by the End User. This client app uses the SP's API.

All traffic would be over HTTPS. Here's how I envision the OpenID Connect process working:

  1. The native app would request a "token" from the SP.
  2. The SP would see the user isn't authenticated and ask for verification from the trusted IDP.
  3. After the user's credentials are provided to the IDP, the IDP would return an ID token and Access token to the SP.
  4. The SP would verify the ID token and give the Access token to the native client app to use for all subsequent requests to the API.

Is this the recommended way to use OpenID Connect in this situation? Any obvious security concerns? The only one I see is that the native client app could use the Access token to access the User Info endpoint at the IDP.

Solution

  • Regarding points 1 - 4:

    1. Tokens requested from IDP not SP. (usually IDP get hosted on separate subdomain). I like STS term (Security Token Service) rather than IDP, which easily describe the role of OIDC server: software that issue tokens.

    2. I prefer to say: every request from the native app to SP, that's protected (not anonymous) must be verified by the STS/IDP. think of IDP as firewall between protected resources/API/SP and native-app/RP/client.

    3. IDP response depends on which flow being used (code, implicit, hybrid, resource owner, client Credential). This gist might help understand flows quickly: OIDC and OAuth2 Flows

    4. ID token designed and meant to be used by the client/RP/native app.

    I think the described use case is very common to be handled by OpenIDConnect+OAuth2. about accessing user info endpoint, its totally depend on your IDP configuration and RP/Client/NativeApp configuration.

    example: I use IdentityServer3 as IDP/STS (its officially certified OpenID Connect Provider): in IdentityServer3 I can disable any endpoint through configuration and restrict RP scopes.

    To sum up: I think the use case is recommended as you concluded. only problem was little misconceptions I highlighted above. but most important is not to choose the wrong flow or abuse the standards through misconfiguration.

    hope its useful.