0

I have a confusion. So, in OAuth2.0 there are 4 types of Grant (Authorization Code, Password, Client Credentials and Implicit). In my use case, I have two login scenario. The first one is using username and password. In this case it's clear that I should use Password grant type to give access and refresh token to the user after they send username and password to the auth server.

In the second scenario, I have users logging in by using OAuth Provider like Google, Facebook, Github, etc. In this situation, once the user grant the permission to my application, I will exchange the authorization code with the access token and use this access token later to get the user info like username, email address, etc. My question is, once I get this user info, which grant type that I should use to return access token from my application auth server so that the user has access to their resources in my application?

In this situation, :

  1. I might only have their email address, but password. So, it's not possible to use password grant type.
  2. client credentials is also not possible because clientID and clientSecret used in this grant type usually belong to a platform like mobile app, web, or any other type of third party application.

any comment will be much appreciated! Thanks

1
  • Hi Imre, what is "my application auth server"? Is the client application federating directly with Google/Facebook, or it redirects to your auth server and then you redirect to FB/Google?
    – Omer Iqbal
    Jun 17, 2019 at 8:53

1 Answer 1

0

I think You may over-complicate this.

In first scenario You do not need OAuth at all - simply implement login and provide the client with some kind of session (cookie for example).

In the second scenario You would use the flow defined by the provider (probably Authorization Code) then when Your server gets the token, it can fetch the user identity form the provider (Google, Facebook, ...) correlate it with Your internal information about user and issue a session.

From now on the user access resources in the same way for both scenarios - using issued session.

If you need distributed authorization for your application also you can implement it that way that the end user application always uses OAuth (Authorization Code flow) but have two multiple providers - social and your authorization server among them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.