We have a third-party website that would like to use OAuth or OpenID authentication to authenticate users against our user database. I have been tasked with implementing said provider, which I would like to do in Python using Flask, but I am having some difficulty wrapping my head around the actual authentication workflow.
All we are looking for here is a basic auth mechanism. When the user wants to use the third party site, they enter their username and password, and we tell the third party site "yes, they are authorized". Due to restrictions on the third party site, this exchange has to take place using OAuth or OpenID - we can't do something simple like having them enter their username and password in a form, submitting it to us, and us sending back a json object or something indicating success/failure.
Here is my understanding of the workflow so far (please correct any false understandings):
- User enters their OAuth userid on the third-party site (client)
- The client creates the proper OAuth URL based on the userid and provider (us), and sends the user to that URL
- The provider responds to the url by displaying an authentication page, where the user enters their password and is authenticated against our database
- The user is then sent back to the client site
This is where I get lost. How does the client know if the user authenticated successfully or not? Does the provider send something in the request indicating this when re-directing the user back? If so, what? Or is it something else - perhaps there are additional steps that get performed when the user is returned to the client?
My main starting point is this page: https://flask-oauthlib.readthedocs.io/en/latest/oauth2.html# which talks a lot about things like Client models and Grant Token models and Bearer Token models and the like - where do those come in? Given my basic needs - I don't, for example, need to track any authorization data, just authentication - can I bypass any of the stuff shown there?
EDIT: So after some more digging, it looks like a "Resource Owner Password Credentials Grant", as described here: https://tools.ietf.org/html/rfc6749#section-4.3 may be what I am going for here. Using that type of grant, it would appear the workflow is:
- User (the "resource owner", in this scenario) enters their username and password on the client page
- client makes a request to our url (whatever we set that up as), containing the username and password in the request body (POST request), along with a grant_type field of "password".
- I authorize the user, and then respond with a json formatted "access token" or error response.
This workflow sounds simple enough (assuming that's what our third-party vendor had in mind), and exactly what I wanted, but leaves me still wondering what all that stuff about Client models and multiple token types, etc is about when looking at the example code.
