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

Question

Usually sessions are used to keep data of a particular 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 a WEB application (client-oauth) that allows a user to log in using their Google account, can manage the session and keep it active and identify the logged in user or know when the user is logged in.

In theory, it would not be Google itself (serve-oauth) that should manage the session instead of the WEB application that used Oauth to authenticate the user?

In short

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 he is logged in?
2. What types of data a WEB application that uses Oauth for authentication receives as Oauth server response when the user is authenticated?

Answer 1

There are several ways. First, let’s go to the questions:

In theory, it would not 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?

She would manage the sessions herself; the Oauth provider only validates access to the information of its registered users.

What types of data a WEB application that uses Oauth for authentication receives 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 validates, and the application receives a token which must be re-validated directly by the server - and only there the back-end application will get data from user who is logging in.

I think the flow can be better visualized 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:
• User connects to your web application. Without 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 request from browser containing the token request - something like http://localhost/?token=1234567.
• The server establishes a direct connection to the back-end Google’s Oauth, passing both the token received as your secret key (for example, https://oauth.google.com/validate/?token=1234567&secret-key=abcdefgh.)
• The Oauth provider validates whether token, secret key and source URL are valid. Positive case, a payload is returned containing user data (JSON: {'email': '[email protected]'}, for example.)
• Your application creates its own session, based on the information returned by Google’s Oauth2 backend.

Two important points:

• Your web application never gets credentials (email + password) directly - these are validated on Google servers.
• Your front-end never receives the secret key, since it should be used only by back-end.