-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add userinfo_endpoint #1454
Add userinfo_endpoint #1454
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -265,6 +265,11 @@ type federatedIDClaims struct { | |
UserID string `json:"user_id,omitempty"` | ||
} | ||
|
||
func (s *Server) newAccessToken(clientID string, claims storage.Claims, scopes []string, nonce, connID string) (accessToken string, err error) { | ||
idToken, _, err := s.newIDToken(clientID, claims, scopes, nonce, storage.NewID(), connID) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm! So we'll be using a JWT for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe @jackielii can answer this one? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Like in my original PR comment: "this is a stop gap solution". In my understanding, access_token is a "key" that should be saved away and later used to retrieve "user_info". Here I'm abusing the ID token signature verification: Use an ID token as the access token, and use signature verification to verify the JWT and just return the claims as the user_info response. Because the access_token is opaque to the user, so this change is forward compatible with the "proper solution". I even created this function to later swap out for the proper "save to db" solution. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @srenatus sorry forgot to answer your original question. Within one auth request, the id_token won't be exactly the same as the access_token, albeit access_token looks and "can" behave like a jwt id_token. We're just abusing the fact that access_token is just a "random string". There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Quite clever! And thanks for considering "forward compat with a proper solution" 😄 |
||
return idToken, err | ||
} | ||
|
||
func (s *Server) newIDToken(clientID string, claims storage.Claims, scopes []string, nonce, accessToken, connID string) (idToken string, expiry time.Time, err error) { | ||
keys, err := s.storage.GetKeys() | ||
if err != nil { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be a "big" TODO. I realised later on that the jose or any other JWT token lib should do all the checks, but I'm not sure they do all the needed. Or maybe they do, and I'm just being over paranoid here to check again. Need a JWT expert or jose expert here to answer the question.