Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OIDC Authentication example? (GitHub, Google, etc) #49

Open
TJM opened this issue Jan 31, 2021 · 3 comments
Open

OIDC Authentication example? (GitHub, Google, etc) #49

TJM opened this issue Jan 31, 2021 · 3 comments

Comments

@TJM
Copy link

TJM commented Jan 31, 2021

I am hoping someone has implemented OIDC Authentication in Gin-gonic, and maybe could share an example?

I am not sure if OIDC authentication would be considered middleware, so I am asking for "exaples" ;)

Maybe there would be some middleware that is just a thin wrapper around go-oidc?

Maybe just adapting some of the go-oidc examples ?

I have been trying to write this as middleware, but I am sort of lost at creating the routes/handlers from within middleware, which is why I am thinking maybe its a mix of example/middleware? I saw favicon "middleware" that looks like it parses every request to see if it is favicon.ico, then handles it, but that seems really inefficient. Can middleware inject routes to be handled by the regular router? (i.e. /auth/login and /auth/callback)

I am also not sure how the "state" would be maintained between the stages (See below)

I also have to assume that it would have to be combined with sessions to provide anything useful?

OIDC Auth (as I understand it)...

Stage 1:

  • When the user wishes to login, this webserver will send them a redirect to an authentication provider (IdP), like accounts.google.com or github or whatever.

Stage 2:

  • Assuming the user successfully authenticates to the authentication provider, it will redirect them back to the application with a token that the go-oidc code can "validate" ... thus proving the user's "identity"

Stage 3:

  • Allow the user to "logout" to end their authenticated session.

So, We would have to have some way for the user to indicate they would like to login (or maybe they navigate to a URL that requires authentication, and the unauthorized page redirects them to login?). The login "handler" would have to "remember" where they were (maybe session can provide this?), and redirect the user to the authentication provider. I was also thinking a dynamic "Login" button could provide this, maybe in combination with the "location" middleware to parse out the return path? Additionally, some sort of "state" string is supposed to be passed to the auth provider (which will be returned) to prevent forged requests.

On redirect (after successful auth), the "callback" would have to "validate" the oidc token and the "state" string, then set the user's session with some useful information (like who they are). The OIDC examples just dump the details out on the screen, which I guess does prove that its working at the most basic level, but then the user probably wants to go visit the pages that require authentication, so it has to be attached to them somehow.

I was thinking that this is where the actual "middleware" would come in. The user could pass a token or "session_id" every time (cookie? or header maybe for API calls) that would be able to "revalidate" the JWT token from OIDC.

Thanks in advance!
Tommy

@TJM
Copy link
Author

TJM commented Jan 31, 2021

For what its worth, here is my initial attempt (not ready for production use, obviously): https://github.com/TJM/gin-gonic-oidcauth

My questions above might make more sense with that context?

~tommy

@sunecko
Copy link

sunecko commented Apr 7, 2024

I did an example with ASP.NET, I'm going to try to recreate it for Gin.

@TJM
Copy link
Author

TJM commented Apr 8, 2024

For what it's worth, the example I posted above is being used for one of our internal apps, and has been working fine. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants