What is the OAuth 2.0 Authorization Code Grant Type?
The Authorization Code Grant Type is used by both web apps and native apps to get an access token after a user authorizes an app. This post is the first part of a series where we explore the frequently used OAuth 2.0 grant types.
Binh Thanh Nguyen
Thanks, nice post
Luís de Sousa
Nice and simple, thank you very much
Joe Green
My understanding is that the application will normally cache the access token and refresh token so that the user doesn’t have to present their login and password repeatedly. How does the application look up up the cached tokens on subsequent accesses? Does an ID token need to be provided to the user agent to identify the user? As a cookie perhaps? Does this need to be signed to prevent masquerading as a different user? Is there a risk of an attacker masquerading as the current user if they intercept the ID token?
Aaron Parecki
There’s many ways to do it, depending on what the architecture of the application is. In a traditional server-side application, the tokens are stored on the server and then you’d use some sort of server-side session to associate that with the browser.
PingPong
What will happen if the user has not signed on?
For internal company, is it possible disable the prompt that user approves app request as mentioned below:
"The user sees the authorization prompt and approves the app’s request"
Can this prompt disabled dynamically?
jensw1000
When you have a service that sends requests to another service without a user involved you could use the “client credential” grant. https://www.oauth.com/oauth…
Ivan Starkov
The thing I dont understand well.
What if attacker intercept authorisation code from callback url (on os level for example using extension or screen reader), then force its own auth process to get valid state parameter for its own session, then just call callback url in its own session using authorisation code from step 1 and valid state from step 2, finally attacker is able to finish auth process as state is not used in exchange of authorisation code and access token.
aaronpk
Yes you’re right, that exact attack is why PKCE exists! PKCE prevents that by requiring the use of an additional secret that the app generates on each request.
Ivan Starkov
Thank you!!! I thought that PKCE is just replacement for implicit flow.
aaronpk
I should clarify. This problem doesn’t exist when the client can use a client secret. It’s only a problem for public clients that don’t have a secret. In that case, PKCE solves the problem, and the Implicit flow has that problem and can’t be solved.
Ivan Starkov
For me it looks like the problem exists for clients with secrets.
This url “example - app . com/redirect?code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3&state=xcoiv98y2kd22vusuye3kch” can be intercepted at user OS level before this request reaches client with secret code (finally its user browser do redirect its not server 2 server communication).
Attacker take code=g0ZGZmNjVmOWIjNTk2NTk4ZTYyZGI3, initiate auth in other browser, get state for his session, and use code above with his own state.
I don’t see this attack can be prevented, as state is not a parameter of exchange code to token.
Aaron Parecki
When there’s a client secret involved, the authorization server requires the client secret in order to use the authorization code. So even if someone did steal the authorization code, they wouldn’t be able to use it, because they can’t have also stolen the client secret.
Ivan Starkov
They will.
Imagine client is a web server with callback url like.
So secret is known only for web server and then browser get from google “signIn” redirect to mysite.com/google/callback?code=GOOD_CLIENT_CODE&state=GOOD_CLIENT_STATE web server can exchange code for access token.
But before browser get redirected and send request to api, nothing prevent “malicious software” to intercept “code” from browser as its shown in browser url.
Then “malicious software” can from other browser just force new auth request, get MALICIOUS_CLIENT_STATE, and then just browse tomysite.com/google/callback?code=GOOD_CLIENT_CODE&state= MALICIOUS_CLIENT_STATE
web server will compare MALICIOUS_CLIENT_STATE with session.state - all will be ok, then
exchange GOOD_CLIENT_CODE using SECRET and then authorize wrong user.
Aaron Parecki
ah I misunderstood what you were describing at first. You’re describing the authorization code injection attack https://tools.ietf.org/html… and PKCE solves that!
Ivan Starkov
Super! Thank you!
toerktumlare
"The application opens a browser to send the user to the OAuth server"
this is a quite a fuzzy explanation. The application itself will not do anything without the initiation of something by the user, and what the user actually does is not described, is it access the api and getting rejected, or is it them clicking the “login” button. Also, what if the application is already in a browser (say website application) does it open another browser, another tab, another page?
Quite fuzzy
Matt Raible
It’s them clicking on a login button. If the application is already in a browser, it’ll usually do a redirect in the same tab, but I’ve also seen some applications use a popup window.
Gautam Nagpal
Is there any option to sent this grant_type as request Body using VBscript or any other script or language ?
Peter Cimring
Thanks, Aaron
There’s one point that confuses me:
To fetch the Access Token, the OAuth spec implies (or seems to imply) that it’s sufficient to pass a client id (without a client secret) - see: https://tools.ietf.org/html…
However, in practice, Authorization Servers seem to require both the client id and the client secret - as you mentioned in the above article.
Have I missed something? (Or is this what the spec means by the “client type” being “confidential”?)
Thanks!