Create a web session from within a 3rd party website using an existing oauth2 token

Question

We're trying to allow a trusted 3rd party web application to automatically authenticate users in our own application. We thought about using oauth2 for that matter.

In our scenario we would provide an oauth2 server and the initial handshake would look something like this (which imho is the regular oauth2 3-legged mechanism). Let's say acme is the name of our service.

1. 3rd party app has a connect to acme button
2. User clicks on that button and is redirected to the acme service
3. User logs in via form based login on the acme site
4. The Acme service presents the user with the 3rd party wants to access your account dialog
5. User clicks accept
6. Acme service generates an oauth2 token and redirects back to 3rd party
7. 3rd party stores the generated token for future interactions with the acme service

Now if the session on the acme website is expired, the 3rd party app could automatically re-authenticate the user in the acme web application by sending an ajax request to an authentication endpoint on the acme server.

It will send the previously stored token in via https as a http header to the acme endpoint, where the oauth2 server will validate the token and authenticate the associated user in the web application.

We're wondering if this implies any security issues or if this is a safe oauth2 pattern for automatically re-authenticating existing oauth2 tokens with a oauth2 providers website.

Answer 1

You got things confused a bit. In OAuth2, you have 3 things :

• OAuth2 Service Provider (acme in your example)
• OAuth2 Client (3rd party in your example)
• OAuth2 User (the browser of the physical user in your example)

Now, what happens is that it's always the client that authenticate himself with the service provider and then the client authenticate the user in its application. The client authenticate the user in its application either by doing it himself (ex. session variable) or constantly re-sending the access token to the service provider.

Now if the session on the acme website is expired, the 3rd party app could automatically re-authenticate the user in the acme web application by sending an ajax request to an authentication endpoint on the acme server.

The wording of that part is strange. It looks like it is the client that is controlling the service provider which makes no sense. The client doesn't really have any control over the service provider. If the session on a service provider is expired and the client ask the service provider if a particular user is still connected, then the service provider will just tell him that he's no longer connected.

Now, what you probably meant is :

The user session with the client (3rd party) is expired, how can I automatically re-authenticate him if the user is still authenticated with the service provider?

Well, there is a couple of ways but first let's talk about the access token. What the user receives from the service provider and then passes to the client is an access token. Access tokens often have limited validity time for multiple reasons check here :

https://stackoverflow.com/questions/7030694/oauth2-why-do-access-tokens-expire

The way to get new access token depends on the service provider. Sometimes the client receive a refresh token that can be used to receive a new access token. See google api for example :

https://developers.google.com/identity/protocols/OAuth2?csw=1

With other providers, the chain of redirect might be automatic if the user is still logged in with the service provider. So, while it do the whole OAuth2 protocol all again, the user only see a page reload.

Additional Note

I saw you mentionned the word "ajax" in your question. There is no ajax in OAuth2 as the security depends on full redirect working properly. Also, it's the client that send the access token to the service provider. The client is a web server, it doesn't do ajax request like we do when we use a browser. And finally, the user cannot send the access token to authenticate himself for so many reasons...