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
My assumptions, plans are the following:
- 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:
user credentials are not exposed to
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)
authentication happens in different domain
Given this point of view, am I missing something very important?