Multiclient approach review

Help
,
1

I’m working on an API based application in which I want to add authentication and authorization using tokens. This because I hope this application will become one of many in a suite of applications and I want to reuse the identities and means of authn/authz. I ended with oauth and openid connect as the means of achieving that. After spending countless hours trying to understand all the technologies involved I hope you can help me validate my assumptions and approach. Basically a sanity check :slight_smile:

My application will have a backend consisting of a set of API’s and two clients. A javascript client used mainly for admins and vendors and a mobile app used by customers of the vendors.

My assumptions, plans are the following:

  • Ideally I would use implicit flow for the javascript client (webapp) and authorization code flow for the mobile app (native app), given we need to assume these clients cannot keep secrets. However it can be acceptable to use resource owner password flow as the resource owner and client (and in the future also potentially the authorization server) are built and maintained by the same company, as-in I’m not planning on allow 3rd parties to use my platform.
  • If choosing for resource owner password flow we should not use refresh tokens in the javascript app as that would be to difficult to protect. In mobile platforms there are secure ways to store refresh tokens.
  • The identity token is not passed to backend API’s. You would pass the access token around, and API’s would call the userinfo endpoint and receive claims about the user which we can use to identity the user.
  • The access token will need to be validated by API’s. It depends on the authorization service what method is used. In auth0 case it will be to use one of the many client libraries to validate the signature (RS256 in my case). Also I need to have logic to validate the scopes (if used).
  • The identity token will need to be validated by the clients in a similar way.
  • We can safely cache access tokens and claims from userinfo at the API side if accounting for expiry.

I relation to the above I have one question though… The main reason why I would not want the use implicit flow or authorization code flow is because of the jarring user experience, the redirects. My standpoint is that it doesn’t matter username and password is exposed to the client as I own and develop both, and that is not likely to change.
I think I understand the security benefits of using the other flows, which are:

  1. user credentials are not exposed to
    client

  2. clientid is not exposed to client, and additional security
    component in the form of the
    authorization code is added to be
    able to retrieve the access token
    (in authorization code flow)

  3. authentication happens in different domain

Given this point of view, am I missing something very important?

2

First of all, that’s a really detailed depiction of your scenario and intentions; I personally appreciate that as it makes any sort of reply easier.

From what you mentioned I would say most of it is spot on, but there are a couple of things that drew my attention. The first is the mention of caching access tokens in the API side; in general I don’t see this happen as access tokens are received in each request, validated and disposed of when the request is completed.

The second point is that the client identifier is always exposed on the client no matter the grant you use, however, the client identifier is not considered confidential information according to OAuth2 so this is not an issue.

Finally, and possibly the most relevant to your question is that relying on the resource owner password credentials grant also means that the client application interacts directly with the token endpoint in a stateless way. This means that if you had two web applications A and B and the same end-user accesses them both then they would have to actively provide credentials at both of them. With the redirect-based flows the authentication process flows through the authorization endpoint which could initiate an authentication session upon the first authentication request and then reuse it for the second; this would mean the end-user would have a simplified user experience due to the possibility of leveraging single sign on.

3

Thanks for the response! This is really helpful.
On the caching, my goal is not to cache the token, but the user info, using the access token as a key in a key value pair. This is from a session management & performance standpoint, reducing round-trip back to the auth server to get user details on each request. The expiry of the access token would determine the lifetime of that cached info.
On the clientid part, this was a typo. it was supposed to be the secret.
Great point on the benefit of 3 legged auth in terms of single sign-on. that is food for thought. Thanks!