Search code examples
djangoauthenticationsessionoauth-2.0openid-connect

What is the standard oAuth/OIDC flow for creating/logging in a user into client server?


Problem:

I want to use information from ID Token (userinfo) to login or create a user for my (app) client server. I am unsure of the standard way to approach this problem as i'm new to oauth and OIDC. My problem lies on the standard flow for creating a session token for my user to access my client server protected routes.

I have successfully logged in with my gmail which includes both my google access token and OIDC ID Token. I have also set up a PostgreSQL data base and user models using django. I have also verified or created a user based on my ID Token information.

I can use data (email, sub, ect) to verify/create user in client database, but what is the standard approach to creating a session token to acces my client server endpoints? If I create a entirely seperate client server session token, do I use any information from the ID Token?

Used this video and auth0 django quickstart tutorial for django integration below.

https://www.youtube.com/watch?v=996OiexHze0

https://github.com/auth0-samples/auth0-django-web-app/tree/master


Solution

  • OpenID Connect doesn't say anything about how you maintain a session between the relying party (your server) and the end users. This is up to you. You could issue a session cookie, or you might issue an opaque token or you could go for a stateless approach with JWTs. OIDC is just about you trusting another entity (IDP) telling you that the user has successfully authenticated and providing you with some basic profile information about the user. What happens afterward is completely up to you to decide.

    But since you mentioned that your application is a Django server, I would recommend using a secure HTTP-only same-site cookie to store the session ID, and then store the information corresponding to said session in some server-side store (in-memory, SQL, Redis.. etc depending on your requirements). This way no information is exposed to the client side which is very good for security and you also spare yourself the overhead of client-side session state management.