CODEWITHSUNDEEP
oauth-2.0jwtauthorizationopenid-connectopenid
XnivaXhzne
XnivaXhzne

Reputation: 41

In Oauth OpenID - Authorization code grant type, where will we exchange the "code" for "access token" and why?

In Oauth Open ID - Authorization Code grant type flow,

  1. We will call the Oauth service provider with the client_id = '..', redirect_uri='...', response_type='code', scope='...', state='...'.

  2. Then from Oauth Service Provider, we will get the authorization code instead of the token.

Q1. So what is the next step? Do we send the code to the back end where the token request will happen or will we call the Oauth service provider from the browser it self?

Q2. Why do we need this additional calls? what problem it is solving?

Q3 After the token is received, how we use it in a typical web application?

p.s: I have read lot of blogs, but unable to get the whole picture. Could you please help me?

Upvotes: 0

Views: 123

Answers (1)

Gary Archer
Gary Archer

Reputation: 29218

Q1. In 2021 it is recommended to keep tokens out of the browser, so send the code to the back end, which will exchange it for tokens and issue secure SameSite HTTP Only cookies to the browser. The cookies can contain tokens if they are strongly encrypted.

Q2. The separation is to protect against browser attacks, where login redirects take place. An authorization code can only be used once but can potentially be intercepted - by a 'man in the browser' - eg some kind of plugin or malicious code. If this happens then the attacker cannot exchange it for tokens since a code_verifier and client_secret are also needed.

Q3. The token is sent from the browser to APIs, but the browser cannot store tokens securely. So it is recommended to unpack tokens from cookies in a server side component, such as a reverse proxy. This limits the scope for tokens to be intercepted in the browser, and also deals well with token renewal, page reloads and multi tab browsing.

APPROACHES

The above type of solution can be implemented in two different ways:

  • Use a website based technology that does OAuth work and also serves web content
  • Use an SPA and implement OAuth work in an API driven manner

Unfortunately OAuth / OpenID in the browser is difficult. At Curity we have provided some resources based on the benefit of our experience, and we hope that this provides a 'whole picture' view of overall behaviour for modern browser based apps:

Upvotes: 1

Related Questions