You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
Stage 2:
Stage 3:
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
The text was updated successfully, but these errors were encountered: