How can a WEB application that uses OAuth for authentication manage the user session?

Usually sessions are used to hold data from a given user after they have logged into the WEB application, and it is the WEB application that is responsible for controlling and managing that data stored in the session. It can use this to identify the user who is logged in to the system and other purposes.

But when I read about the protocol OAuth, I didn't quite understand how that a web application (client-OAuth) that allows a user to log in using your Google account, you can manage the session and keep it active and identify the logged in user or know when the user is logged in.

In thesis, wouldn't it be Google itself (serves-oauth) that should manage the session instead of the WEB application that used OAuth to authenticate the user?

Summarizing

  1. as a WEB application that uses OAuth for authentication, it can manage the session and identify the user who is logged in, or know if is he logged in?
  2. what data types a WEB application that uses OAuth for authentication receives as OAuth server response when the user is authenticated?
Author: Comunidade, 2017-06-12
Source

1 answers

There are several ways. Before, let's go to the questions:

In thesis, wouldn't it be Google itself (serve-oauth) that should manage the session instead of the WEB application that used OAuth to authenticate the user?

No. Google is responsible for user authentication and verification of the validity of user information requests made by web applications.

As a WEB application that uses OAuth for authentication, it can manage the session and identify the user who is logged in, or know if he is logged in?

It would manage the sessions itself; the OAuth provider only validates accesses to the information of its registered users.

What data types does a WEB application that uses OAuth for authentication receive as a response from the OAuth server when the user is authenticated?

There are several formats, but in general the flow is designed to segregate layers - via the web the user it validates, and the application receives a token that must be re-validated directly by the server - and only then the back-end of the application will get the data of the user who is logging in.

I think the flow can be better viewed if the steps are listed in sequence:

  • your web application is registered with the OAuth provider. This will generate a secret key, which you will use in the future:insert the description of the image here
  • user connects to your web application. Without an active session, you offer a page containing a list of OAuth providers that the user can use. The user selects, for example, Google.
  • the browser is redirected to Google's OAuth2 provider, along with a valid return URL (previously registered - in the image above, http://localhost was used).
  • user authenticates.
  • Google redirects back, along with a request token.
  • your server receives a browser which contains the request token - something like http://localhost/?token=1234567.
  • the server establishes a direct connection to Google's backend OAuth, passing both the received token and its secret key (for example, https://oauth.google.com/validate/?token=1234567&secret-key=abcdefgh.)
  • the Oauth provider validates if token, secret key, and Source URL are valid. If so, a payload is returned containing the user data (JSON: {'email': '[email protected]'}, for example.)
  • USA application creates its own session, based on the information returned by Google's OAuth2 backend.

Two important points:

  • your web application never receives the credentials (email + password) directly - These are validated on Google servers.
  • Your front-end never receives the secret key, since it should only be used by the back-end.
 3
Author: OnoSendai, 2017-06-12 19:14:10