Our current authorization mechanisms are somewhat ad hoc. We use OAuth2 scopes for Insights, but in a way that is probably too resource specific and verbose. Most courseware access questions go through edx-platform's access.py checks. Other apps generally identify the caller and make their own decisions about what they should and shouldn't be allowed to do.
Read/Watch these first:
http://nordicapis.com/api-security-oauth-openid-connect-depth/
| Widget Connector | ||
|---|---|---|
|
OAuth 2.0
We've chosen to use OAuth 2.0 as the basis of our API authorization scheme, as it is both simpler and more widely adopted by the Python community than SAML-based solutions. However, OAuth 2.0 is interesting in just how much it leaves unspecified, particularly in the information passed between the Authorization Server and the Resource Server.
...
Cloud Foundry uses this approach with their UAA, and Salesforce and Oracle both use this form as well. Both Salesforce and Cloud Foundry started out using symmetric HMAC-SHA256 signing and later shifted to using RSA-SHA256. Since RSA-SHA256 would mean that the signing secret would only have to live in the Authorization Server, we'd almost certainly want to start with that approach unless we ran into prohibitive performance problems.
Nimisha pointed out the video included at the top of this page, where the suggestion is to return an opaque token to the untrusted end user/client, but to use AS signed JWT tokens internally between services. This gives us a bit more depth in our security.
Scopes
Scopes are a simple list of case-sensitive, space delimited permissions in OAuth 2.0. The client can request a list of scopes when asking the AS to issue an access token, but the AS can override those. If the Client doesn't ask for scopes, the AS can give a reasonable default or fail the request. There are no restrictions beyond that, and different groups have adopted very different naming practices (many ignoring the "space delimited" rule). A Heroku engineer wrote a blog post with a good survey of these approaches.
...
The service code should still express things in terms of permissions internally of course, but the mapping of roles to permissions should happen at the service level.