Using openid-connect for authentication spa and rest api

Question

I have an API Server (Resource server) and multiple apps, Web GUI (SPA) and a Desktop client and maybe more coming. I'd like to use openid-connect besides http basic authentication for my API Server. It should be configurable which openid provider to use. My own, facebook, google... I only want to do authentication, I do not need their API. I only need some profile data like email or firstname.

Let's say I have configured google as my IdP and I'm currently using my Web GUI (SPA). I need to login, no problem, according to https://developers.google.com/identity/protocols/OpenIDConnect I redirect the user to google, get my authorization code and the Web Gui (SPA) gets an id_token and access_token from google.

No problem so far, but now the SPA has to work with my API Server and the API Server needs to authenticate every request (since it is a stateless rest api) coming from the Client (WebGui SPA) and needs to know which user actually did this.

A

So the access_token from google is meant to be used to access google api's right? But I also could just pass this access_token with every request to my api server and the api server calls https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=xxx to verify the access_token and get the account name (mail). But this doesn't sound right, does it?

B

I also have and id_token which I can verify without calling google server everytime. So could I also just pass the id_token as bearer with every request to my api server and the api server can verify the id_token? But according to openid-connect spec the access_token is actually the one which just get passed to the api server and the id_token must stay on the client. But then the id_token would be completely useless to me, the API server needs to know who the user is, the client (Web GUI) doesn't really care.

C

Or since it is my own API Server, does my API Server actually needs to implement the whole oauth2 system by itself, just not authentication but creating access_token and more. So I would have a /api/tokensign to which I can pass the id_token from google, the API verifies the id_token and creates an access_token for my WebGUI (SPA). And this new access_token can be passed as bearer to every api request. This actually sounds as the best solution according to specs, but do I really need to implement oauth2 by myself into my API? Sounds like a heavy addition since A and B could also be implemented.

My rest-api needs authentication with every request so is A, B, C the right approach? Please don't tell me this is opinion based, it is not. What is the right way using oauth2/openid-connect for authentication?

Answer 1

You can use all three methods you have mentioned above, but indeed with some considerations. I will explain them with regards to available specifications.

Scenario - Two systems S1, S2

• S1 - Identity provider
• S2 - API endpoint

What you need - Trust and use 'Tokens' issued by S1 to access S2

Explanations for proposed solutioins A, B and C

A - Verify tokens issued by S1 for each call

This can be done using the RFC7662 - OAuth 2.0 Token Introspection endpoint. This validation is valid by the specification so yes you can use the token verification endpoint.

Advantage for this method is that, if a token is revoked, the effect is instantaneous. The very next API call will fail. But indeed there's the implication on performance. You need an extra verification service call.

Note that you do not need to get the account name from this verification response. It could be taken from ID token and could be used to verify for extra protection.

B - Trust tokens issued by S1 for each call

Now this approach is something extended from RFC6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage. You can indeed use ID toke to authenticate and authorise an end user. This link contains a good explanation on the ID token usage as a bearer token.

You can indeed verify the validity of token using MAC and even encryption. But be mindful to use short lived tokens and to always use TLS. And be mindful about refreshing tokens.! Because according to openID connect specification, ID token is not a mandatory item for a refresh token request.

C - A wrapper for federation

For this you can write your own solution or use an existing solutions (ex:- WSO2 identity server). This identity server will configured to choose the identity provider on your application (client like desktop app or web app). Identity server will do the necessary redirects and provide you the required tokens. But indeed you will need to use introspection endpoint to validate the token validity.

If you go one step ahead of this solution, you can try to implement a code exchange mechanism. You can exchange the token carry from external to tokens issued internally by one of your system (ex:- Google access token to your internal access token). The advantage of this approach is you have control over validation. Also since subsequent token validations are done internally, there should be a performance improvement.

Hope this explains some doubts you have.