How to send the ID or access token from frontend to backend in OpenID connect

Viewed 1519

I have a frontend developed in React and backend developed in Spring Boot. I have a authorization server of my company. Now we are planning to authenticate the user using OpenID connect. When a user tries to load our website it should redirect to the authorization server for login. Now the authorization server should send us the code that can be exchanged for the id token and the access token.

So to achieve this the flow that we are doing is ,

Step1 :Authorization code will be exchanged for id token and access token from our backend. Frontend will send us the code that it received in redirect uri and the backend will then call the token endpoint of authorization server to get the access code.

Step2.Now once we recieve the token , we will send that ID token to the frontend to store it in local sesion/storage so that every request that is made from the frontend for that user has the token in the header.

Now my concern is 1.Should we send the id token /access token to the frontend?? 2.If we send the token to the frontend then we must encrypt it for security,so that now for every request that comes from frontend for that user ,the backend will get the encrypted access token in the header from the frontend and it could then decrypt it from the private key, send it to authorization server for validation and process the request and give access to the APIs written in backend.What encryption mechanism could be used here??Is this the right approach?

I don't want to use the implicit work for security reasons.I don't want to expose my token to the browser.

1 Answers

Your SPA would send access tokens to backend APIs, which will verify its JWT signature, then use the access token's scopes and claims to authorize access to data. An ID token just provides proof of the authentication event to the SPA, eg to inform it about how the login occurred.

Whether or not an access token is encrypted, an attacker can send it to APIs and get data, so encryption of access tokens is very rarely used. Instead, it is recommended these days to avoid using tokens in the browser at all, to reduce Cross Site Scripting risks. Instead use only the latest secure cookies, which can contain access tokens, as long as you stay within cookie limits. See SPA Best Practices for further details.

Using cookies in an SPA is tricky. The best architectural option is to issue cookies via APIs, so that you keep development focused on React only. At Curity we call this the Token Handler Pattern, since API utility components manage tokens on behalf of the SPA, and issue cookies when required. Some further links below:

Related