From e89e1a403843bd59879a4372fbada2eda61028a8 Mon Sep 17 00:00:00 2001 From: Robert Raposa Date: Tue, 14 Jul 2020 09:57:30 -0400 Subject: [PATCH] update oauth_dispatch ADRs to accepted (#24474) The following oauth_dispatch ADRs are being marked as accepted, because they were implemented and are in use in Open edX. - 0006-enforce-scopes-in-LMS-APIs.rst - 0007-include-organizations-in-tokens.rst Given that, scopes have still not been widely adopted in Open edX, which would require additional decisions and investment. --- .../0006-enforce-scopes-in-LMS-APIs.rst | 2 +- .../0007-include-organizations-in-tokens.rst | 16 ++++++++-------- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0006-enforce-scopes-in-LMS-APIs.rst b/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0006-enforce-scopes-in-LMS-APIs.rst index d9d1679889..547d8a7427 100644 --- a/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0006-enforce-scopes-in-LMS-APIs.rst +++ b/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0006-enforce-scopes-in-LMS-APIs.rst @@ -4,7 +4,7 @@ Status ------ -Proposed +Accepted Context ------- diff --git a/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0007-include-organizations-in-tokens.rst b/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0007-include-organizations-in-tokens.rst index 134bdc4509..5f3e4d181c 100644 --- a/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0007-include-organizations-in-tokens.rst +++ b/openedx/core/djangoapps/oauth_dispatch/docs/decisions/0007-include-organizations-in-tokens.rst @@ -4,7 +4,7 @@ Status ------ -Proposed +Accepted Context ------- @@ -42,9 +42,9 @@ Here are a few organizational relationships that exist in the edX system: do so either via a. bulk APIs using the *Client Credentials grant type* (e.g., to - synchronize their own data in a background process) or + synchronize their own data in a background process) or - b. a user-specific API on behalf of a logged-in user via the + b. a user-specific API on behalf of a logged-in user via the *Authorization grant type* and *edX as the identity provider* (e.g., to display user-specific data on their own portal). @@ -100,7 +100,7 @@ organization information to the granting end-user. "content_org:Microsoft" -* For a token created on behalf of a user (*not* created via a +* For a token created on behalf of a user (*not* created via a *Client Credentials grant type*), the token is further restricted specifically for the granting user. And so, a "user" filter with the value "me" would be added for this grant type. @@ -137,7 +137,7 @@ Token Examples Client Credentials (server-to-server) grant type ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -When a trusted application makes server-to-server calls, the application's +When a trusted application makes server-to-server calls, the application's service user info is included in the JWT and the *filters* field includes the organization identifier and type associated with the application. @@ -166,7 +166,7 @@ filter “me” in the *filters* field. "version": "1.0", "preferred_username": "ajay_mehta", ... - } + } Consequences ------------ @@ -191,7 +191,7 @@ Consequences make sure there are no security issues introduced where old endpoints that are not aware of the new filter do not enforce it. Possible ways of doing so are: - + * Endpoints that are highly security sensitive should reject any token that includes an unrecognized filter. @@ -206,7 +206,7 @@ Consequences they don't recognize. For example: "grades:read:content_org" - + Additionally, this alternative would allow tokens to specify different filters for different scopes.