0

I am currently working on personal project, implementing an authorization server in Rust for the OAuth 2.0 protocol. Specifically, I am trying to implement the Authorization Code Flow with PKCE, Device Code Flow, and Client Credentials Flow. For the most part, I have the endpoint routes setup and database tables setup to store the information, and was able to setup client credentials authorization easily enough.

However, when reading posts online about auth code and device code flow, I have noticed what I would consider a sort of "hand-waviness" for the step where the user authenticates and grants permission on the authorization server. I understand that the authorization server should present the user with some login prompt, and with existing identity providers like Okta, Google, etc. I believe that prompt is usually a webpage that asks the user for their email/username and password.

As such, I have setup a Users DB table, and created a few Yew webpages in order to facilitate this prompt, however am confused as to the connection that should be made between this prompt, and the code grants. The following is my guess as to what usually/should occur:

  1. Resource Owner wants to access some resource protected by the Authorization Server while using the Client
  2. Client make an authorization request to the Authorization Server's /oauth/authorize or similarly named route
  3. Assuming a valid request from the Client, the Authorization Server responds to the request with a 302/303 response and redirects the Resource Owner to the Authentication Prompt
  4. The Resource Owner enters in their credentials that they previously registered with the Authorization Server
  5. Assuming valid credentials, the Authorization Server displays the scopes being requested by the Client to the Resource Owner for verification
  6. Assuming the Resource Owner confirms the scopes being authorized, the Authorization Server then replies with another 302/303, this time returning back to the Client's registered callback URI with the specified payload from the RFC.

I have two primary questions that arise from this:

  • The first and foremost is if this flow sounds/looks right. It's primarily from just observing the oauth playground flow, as well as the documentation/flow of existing identity providers that I know of.

  • The scond is, assuming this flow is correct, is there some way that an authenticated user can be identified by the authorization server's login prompt without implementing an authentication service specifically for the prompt flow? I eventually plan on adding OpenID Connect functionality to the authorization server as well, as that was one of my primary reasons for making the authorization server in the first place. It just feels silly that in order to allow for oauth 2.0 authorization, I would need to implement a basic/"less secure" authentication system (I know oauth is for authorization, referring more to the prompt auth system being less secure than OpenID Connect here) just to allow users to, well, authorize and eventually authenticate. As such, I feel like I'm missing something here.

Actions Attempted I have attempted to observe some OAuth flows of existing Identity Service Providers, as well as read the RFCs for OAuth 2.0 and more specifically for Authorization Code and Device Code flow, and finally research the topic online to no avail.

Additionally, I am considering adding an authentication system to my authorization server's code prompt flow to allow user's to sign in and authorize the code flows, but as mentioned above as that does not seem right, would like to confirm that's the correct route to go before continuing forwards.

Relevant Links
Interactive Resources:

RFCs

Google Results:

quasius-like-cautious
  • 33
  • 8
  • After a bit more research online, I was able to locate the following SO article which outlines that the Authorization Server requires Authentication but the implementation is not in scope: https://stackoverflow.com/questions/33702826/oauth-authorization-vs-authentication. – quasius-like-cautious Mar 24 '23 at 21:33

0 Answers0