0
votes

I'm currently unfamiliar with the OAuth2.0 Authorization Code Flow and I've read many articles about it and currently I still don't know how to properly implement it. So far, what I know about the flow:

  1. User Logs in using OAuth
  2. User is redirected to the authorization server for authorization code
  3. Callback for permission/scope
  4. Redirected to authorization server for access token in exchange for authorization code
  5. Redirect back to the client with the access token
  6. Client uses access token to access resource server.

Right now, what I'm still confused is that where should the login validation come (Login of username - password)? Is it a separate validation before going to OAuth flow and once the user is valid, it should go back to the flow?

3

3 Answers

0
votes

I have some resources that explain OAuth 2.0 using Google Sign in as an example. Let me try to rephrase it according to your question.

Let's use the example of a user logging-in to Intercom using "Sign in with Google".

  1. The user presses the button "Sign in with Google". This will redirect to the identity providers /authorize endpoint (could be different for each provider) which go to their login page.
  2. The user is redirected to Google's accounts page. If not already logged-in, the user can enter their Google email/password here.
  3. Google redirects back to Intercom with an authorization_code (for example, it redirects to https://intercom.com/authcallback?code=XYZ...)
  4. Intercom's backend server sends this authorization_code with the client_id and client_secret (from their project in google), and receive an access_token (usually to the /token endpoint)
  5. Intercom can then use the access_token to access the user's profile from Google.

So to answer your question, the user can enter their email/password inside the OAuth provider's page. Keep in mind that OAuth 2.0 doesn't specify how the provider is authenticating the user. This means, that the OAuth provider can authenticate their users in different ways, like email/password, email magic-link, SMS OTP, etc. Your website is just supposed to trust the OAuth provider that they are authenticating the user for you correctly.


Some extra resources that would help you understand OAuth 2.0 more:

0
votes

login validation come (Login of username - password)?

OAuth 2.0 NOT an Authentication protocol

The OAuth 2.0 specification defines a delegation protocol

Any use of username - password is outside of OAuth 2.0 and you should be looking at Open ID Connect which is an authentication protocol built on top of OAuth 2.0.

Best current Practice for Authorization Code flow is to use PKCE on OAuth or OpenID Connect.

0
votes

The usual solution is to externalise both OAuth 2.0 and Open Id Connect from your code by using a mature security library. When you're new to this type of security there is a learning curve. My resources will give you an idea of how it all fits together:

The libraries you integrate depend on the technology stack you are using. The resources above are for a Single Page App and NodeJS API.