CODEWITHSUNDEEP
oauth-2.0oauthoauth-provider
ArguablyADumbass
ArguablyADumbass

Reputation: 1

Is This OAuth 2.1 Design Pattern Suitable for a Custom Provider?

I'm currently designing an OAuth 2.1 provider and would appreciate feedback on whether my approach is solid or if there are areas that could be improved.

I noticed there aren't many real-world flow diagrams available, so I created one to illustrate my current design. Below is an overview:

Oauth2FlowDiagram

Flow Overview:

User Initiates Sign-In:

The user starts the sign-in process on the client app (e.g., someapp.com). They choose to sign in using the custom provider.

1. Redirect to Custom Provider:

The client app redirects the user to the custom provider’s sign-in page. The provider validates the URL and OAuth parameters.

2. User Credential Validation:

The user enters their credentials, which are validated directly against the provider's database (no external HTTP queries or redirections are involved).

3. User Consent:

After validation, the user consents to share their information with the client app.

4. Authorization Code Generation:

The provider’s backend creates an authorization code and stores the relevant data in its database. The provider then redirects the user to the client's callback URI, including the necessary parameters (e.g., code, state, etc.).

5. Token Request:

The client app requests a token from the provider by exchanging the authorization code, along with the client ID and client secret. This occurs server-to-server, outside the user’s session.

6. Token Issuance:

The provider validates the request and issues an access token.

7. User Data Request:

The client app uses the access token to request the user’s OpenID, email, name, or other permitted scopes from the provider’s database.

Upvotes: 0

Views: 17

Answers (0)

Related Questions