I am completely new to oauth2. I need to implement oauth2 for securing my REST services. After reading different blog posts what I under stood is,
There are 3 things, Client,Provider and webapp.
Web app Wants to access information about the user from the provider.
If the client allows , provider will give a authorization code to the client and webapp in query string.
Now the web app will use the authorization code to obtain the access token using which it can access the resources.
Now I am bit confused regarding the authorization code. Is it secure ?
What is the life span of a authorization code? If someone else will steal the authorization code will he be able to access the user resources?
RFC 6749 recommends that the maximum lifetime of an authorization code be 10 minutes (4.1.2. Authorization Response). In other words, an authorization code expires in 10 minutes.
An authorization code is just like a ticket which is exchanged with an access token at the token endpoint. An authorization code is not an access token, so no one can access any data with an authorization code. In addition, an OAuth 2.0 server will discard or invalidate the authorization code after the exchange.
These two request have to be done over HTTPS (mandatory) since they are requests to the OAuth server which has to support only HTTPS. It's only the client/requestor server who do not have to support HTTPS, so only the Auth Code is potentially sent in clear over HTTP. But the Auth Code is useless without the client ID/Secret. Basically the point of the OAuth Code flow is that the burden of having an SSL-enabled server is on the OAuth Provider (Google/Facebook etc...) and not on the users of the APIs
Related
In Oauth Open ID - Authorization Code grant type flow,
We will call the Oauth service provider with the client_id = '..', redirect_uri='...', response_type='code', scope='...', state='...'.
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?
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:
Code
Docs
In OAuth2.0 Authorization Code Grant as stated in RFC 6749, the token request requires client secret according to sec4.1.3; however, the authorization request is not according to sec4.1.1.
Does anyone know why? It seems using client secret for both authorization and token request makes the process more secure.
They are different because they are two different types of requests. 4.1.1
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com
Is used to display the actual consent screen to the user.
Once the user has accepted then the code is exchanged for an access token
>HTTP/1.1 302 Found
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA
&state=xyz
No secret is needed because you are currently in the Authorization Code section of the document.
4.1. Authorization Code Grant
The authorization code grant type is used to obtain both access
tokens and refresh tokens and is optimized for confidential clients.
Since this is a redirection-based flow, the client must be capable of
interacting with the resource owner's user-agent (typically a web
browser) and capable of receiving incoming requests (via redirection)
from the authorization server.
Authorization Code is sometimes refereed to as the Implicit flow, as the required access token is sent back to the client application without the need for an authorization request token. This makes the whole flow pretty easy, but also less secure. As the client application, which is typically JavaScript running within a Browser is less trusted, no refresh tokens for long-lived access are returned. Returning an access token to JavaScript clients also means that your browser-based application needs to take special care – think of XSS (Cross-Site Scripting) Attacks that could leak the access token to other systems.
Basically a user implicitly trusts their pc so there is really no need for the client secret validation step. Client secret is only needed for server sided applications where the user does not have access to the server so the server must validate itself.
I have been reading different flows of OAuth and have confusion about the Authorization Code flow. It is said that Authorization Code Flow is more secure because even if the authorization code is hijacked while transfer, it is useless to the hacker because the the hacker would need the client id and client secret to acquire the access token - but what if when the client requests for access token after receiving the authorization code, the hacker hacks the transmission and get the access token?
I don't know but it looks like the Authorization code is only adding an extra layer of security but not actually completely securing the access tokens.
Am I right? Please correct me.
The typical use case for an Authorization Code flow is that the token request (i.e. the one that exchanges the Authorization Code for an access token) is done over a TLS protected backchannel which means that the attacker cannot get to it - unless he's able to break SSL in which case there are much bigger problems.
But for front-channel use case, i.e. an in-browser Javascript application or Single Page Application you are right: a hacker could almost just as easy intercept the token request as the redirect. That is also why that use case cannot use a confidential client since the secret would be too easily exposed.
The Authorization code flow makes sense when you have a frontend client which also has access to a backend which can securely talk to the auth server.
The flow would be as follows:
The frontend client redirects the user to the auth server url
the auth server (after login), redirects the user back to the frontend client redirectUri
the frontend client extracts the code from this url and passes it on the backend.
the backend then exchanges this code for an access token by directly interacting with the auth server.
The backend to auth server communication is what the hacker can't intercept (easily).
In OAuth 2.0 flows the authorization server sends the authorization code to the redirect endpoint and then the webpage has to hit the server again to get a separate access token to query the protected API with.
Why do there have to be two tokens? Specifically could someone provide example(s) of security attacks/vulnerabilities that emerge without this design.
There is this post Facebook OAuth 2.0 "code" and "token" but it doesn't really fully explain the reasoning behind the design.
One (the authorization code) is exchanged in the frontchannel, the other (the access token) in the backchannel. The end goal is obtaining the access token. Since the frontchannel is inherently more insecure it makes sense to send a very short-lived one-time-usage-only temporary credential (i.e the authorization code) in the front channel that the web server can use to obtain the longer-lived repeatedly-usable access token in the backchannel. That backchannel call would also allow for the web server (or: Client) to authenticate itself to the Authorization Server to increase the assurance about dealing with the right party.
I'm learning about O Auth 2 from here
I was wondering in the step of "Authorization server redirects user agent to client with authorization code", why doesn't the server just give the access token instead? Why give an authorization code that then is used to get the access token? Why not just give the access token directly? Is it because there there is a different access token for each resource so that you need to go through O Auth again to access a different resource?
The authorization grant code can pass through unsecured or potentially risky environments such as basic HTTP connection (not HTTPS) or a browser. But it's worthless without a client secret. The client can be a backend application. If the OAuth2 server returned a token, it could get compromised.
There is another OAuth2 flow - the Implicit flow, which returns an access token right after the authentication, but it's designed mainly for JavaScript applications or other deployments where it's safe to use it.
If a malicious app gets hold of the client id of your app(which is easily available, for example one can inspect the source), then it can use that to retrieve the token without the use of the client secret. All the malicious app needs to do is to somehow either specify the redirect URI to itself or to tap into the registered redirect URI.
That is the reason for breaking the flow as such. Note, when the client secret is not to be used as in SPA (Single Page Apps) or Mobile Apps, then PKCE comes to the rescue.
There is a reason for breaking up the authorization flow so as to keep the resource owner's interaction with the authorization server isolated from the client's interactions with the authorization server. Therefore we need to have two interactions with the authorization server. One in which the resource owner authenticates with it's credentials to the authorization server. And another where the client sends in it's client secret to the authorization server.
Please also see PKCE that deals with SPA (SinglePageApp)/Mobile apps.