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

Clarification on oAuth implementation #1075

Open
bradwilladsen opened this issue May 23, 2018 · 1 comment
Open

Clarification on oAuth implementation #1075

bradwilladsen opened this issue May 23, 2018 · 1 comment
Labels

Comments

@bradwilladsen
Copy link

We are looking to implement oAuth 1.0a into our LRS and I would like for someone to verify my understanding of the spec.

  • The table outlining the various scenarios for oAuth support here seem to imply both 3 legged (Known user) and 2 legged (Unknown user) oAuth implementations. Is this correct? If so, the LRS only needs to support one of these methods to be compliant?
  • The No Application/Known user is really just Basic auth, and has no relation to oAuth.
  • The User Unknown/Application Is Registered section is confusing with the "OAuth token steps are not invoked". Can I get more clarification on what this means?

The endpoints outlined here appear to be specific for a 3 legged implementation. Can someone clarify my interpretations of these endpoints?

  • The endpoint /OAuth/initiate provides an application token (even though it says temporary token) for a specific consumer key.
  • Once you obtain your application token, call /OAuth/authorize with your scopes as query parameters, and an authorization header outlining the user credentials to generate a new authorization token. This new token should be persisted in some fashion as it contains the relationship between this user, token and their scopes.
  • To obtain a token to access the LRS, call /OAuth/token with an authorization header to generate the token (that probably has some sort of expiration on it) with the authorization token from the previous step (/OAuth/authorize). This token also needs to be persisted for the protected resource so it can verify the signature.
  • The LRS (protected resources) verifies the signature from the request using the token information that was persisted in previous request (/OAuth/token)

Thanks in advance!

@bscSCORM
Copy link
Contributor

bscSCORM commented Jun 6, 2018

@bradwilladsen based on the call, it sounds like you're likely trying to integrate with a customer of ours, so it makes sense for us to take this off of GitHub and presumably set up a thread or meeting with our mutual customer to work through this. You can email me at [email protected]

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

No branches or pull requests

3 participants