OAuth2 flow – does the server validate with the Auth server

oauth2Security

I've been reading a lot on OAuth2 trying to get my head around it, but I'm still confused about something.

I understand that the client authorises with the OAuth provider (Google for example) and allows the Resource Server to have access to the user's profile data. Then the client can send the access token to the resource server and be given back the resource.

But what does not seem to be covered in any of the documentation is what happens when the client app asks the resource server for a resource and passes it the access token. Everything I have read so far states that the resource server just responds with the requested resource.

But that seems like a huge hole, surely the resource server must somehow validate the access token, otherwise I could just fake up any old request and pass an old, stolen, fake, or randomly generated token and it would just accept it.

Can anyone point me at a simple to follow explanation of OAuth2 because so far the ones I have read feel incomplete.

Best Answer

Found it. Buried in the spec. They say the resource server should validate the access token with the auth server but that it's outside the scope of the document. Pity, I would have thought that token validation was an important part.

Related Solutions

Should OAuth token be shared to implement SSO

I think you are getting a little confused there.

SSO comes into question when there are two or more apps involved(ex: gmail, google drive and google plus are three different apps that have SSO, you sign in into one of them, the others will have signed in automatically). Are there two applications in this question?

You don't share the oAuth access token with the client. By client, I believe you mean the browser anyway. You keep the oAuth access token in the server tied to the user session or persist in the database. The oAuth access token will expire after some time(exact time is specified in the response). When the access token expires, you get a new access token with the refresh token that you saved when the user first authorized your application at the provider. You have to keep the refresh token forever by persisting in the database. By any means, if you lose the refresh token, you should have the user sign-in into the oAuth provider site and get the authorization done again so you'll get the refresh token.

Architecture for OAuth2 – BackendServer – FrontendServer

First, you will need HTTPS.

HTTPS = HTTP + SSL/TLS.

It creates a security layer on top of your HTTP and prevent a lot of attacks. For that layer to work you will need to trasmit and receive credentials in a form of an certificate. see HTTPS

HTTPS can be configured in One-Way or Two-Way.

One-Way: In the One-Way scenario only you send your server certificate to the client. He will verify it, and if it is ok, he will start the communication right away.

Two-Way: It happens after the one-way, but the client send his certificate to your server so you can get a chance to verify it. Only when you respond that you trust the certificate the communication will begin.

This is a configuration that you do on the servers. Your application/API will use HTTPS on your server to send/receive information.

Second, Here is a complete flow in OAuth2 with all steps.

In the picture above:

User: Is the host (end-user or server) requesting something to you on you application server.
Client: Is an application server that is connected to your Auth Server.
Auth Server: Server that you OAuth Authentication Server is running.
Resource Server: Is the API server used to access the user's information.

Once this flow is complete your 'user' is autenticated and have a token. By 'user' i mean user in an application or an api.

The 'user' then use the token in every request till the token expires.

In your case,

Your Rest Api will receive the token, in the Authorization header of the HTTP request rfc scpec link section 14.8 Authorization.

Authorization: Bearer mF_9.B5f-4.1JqM <- (token is here)

Then you need to check the token in your OAuth server to validate it.

This is happening on the last request between Client and Resource Server in the above picture.

GET /resource(access_toke)
200: response <- (token is valid)

If the token is valid then you can grant acess to the requested resource. If not you deny the request by returning a http status code of 401 (Unauthorized) see discussion on stackOverflow.

Third, you will need to protect your server against replay attacks.

see discussion on securityExchange.