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

Example validating requests with acess tokens #21

Closed
cristiangraz opened this issue Jan 14, 2016 · 4 comments
Closed

Example validating requests with acess tokens #21

cristiangraz opened this issue Jan 14, 2016 · 4 comments
Assignees
Milestone

Comments

@cristiangraz
Copy link
Contributor

All of the examples show how to create authorization codes and access tokens, but there is no example to show how to actually verify the access token on an incoming http request. I looked through the library and think the functionality may be missing since it's more than just calling the storage's GetAccessTokenSession, but wanted to discuss first to see if I had missed it.

@aeneasr
Copy link
Member

aeneasr commented Jan 14, 2016

Hey good point, this is currently missing. Once #20 #18 are merged I'll look for a good place to document this

@aeneasr aeneasr added the docs label Jan 14, 2016
@aeneasr aeneasr self-assigned this Jan 14, 2016
@aeneasr aeneasr added this to the v0-jwt milestone Jan 14, 2016
@cristiangraz
Copy link
Contributor Author

In case anyone comes across this in the meantime, I was able to get this working with the code below, but wasn't able to get the signature validation against the bearer token working ahead of the storage lookup... the client (secret) isn't available off of just an access token.

accessChallenge := &enigma.Challenge{}
accessChallenge.FromString(bearerToken)

var session oauth.Session
ar, err := store.GetAccessTokenSession(accessChallenge.Signature, &core.TokenSession{Extra: &session})
if err != nil {
    api.GetError(OAuthInvalidAccessTokenError).Send(c)
    return
}

// Token is valid

@aeneasr
Copy link
Member

aeneasr commented Jan 15, 2016

Hey @cristiangraz yes indeed, not having the client secret around is actually a problem with validating the token cryptographically using HMACSHA. Maybe #18 will suit you better?

I'd like to keep the client secret for validating the tokens because it enables us to invalidate tokens when the secrent changes.

@aeneasr
Copy link
Member

aeneasr commented Jan 20, 2016

Closed as per #18

@aeneasr aeneasr closed this as completed Jan 20, 2016
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