[FC-0118] docs: add ADR for standardizing authentication patterns#38301
Conversation
|
related doc worth reading: https://docs.openedx.org/projects/openedx-proposals/en/latest/best-practices/oep-0042-bp-authentication.html#consequences, we can make changes to the ADR based on the attached doc if needed. |
Faraz32123
changed the title
Faraz32123
force-pushed
the
docs/ADR-standardize_authentication_patterns_and_security_scheme_usage
branch
from
f5cb0c1 to
a6a25d3
Compare
| authentication mechanism for all API access** (external and internal), per `OEP-0042`_ | ||
| 2. **``BearerAuthentication`` and ``BearerAuthenticationAllowInactiveUser`` are | ||
| deprecated and MUST NOT be used in new code** | ||
| 3. **Session authentication MUST be used only for browser-based UI interactions** |
There was a problem hiding this comment.
I'm not sure if this distinction is super important. What is the bad thing that happens if your API endpoints support session auth also? Right now DRF in openedx-platform supports both by default: https://github.com/openedx/openedx-platform/blob/master/openedx/envs/common.py#L822-L825 and I don't see a problem with that. I think it's more valuable that all endpoints support any valid auth scheme than having API calls not support the browser.
There was a problem hiding this comment.
@feanil I think you have valid point here that we should support any valid auth scheme instead of categorizing them on the basis of their usage.
I am adding a new commit that addresses above point with some additional remains(includes removal of JWT issuers & use of asymmetric keys) of OEP-0042, But it had some consequences(Link) that you might want to look in. That way we can decide the scope of this ADR. And we can remove the part that is not needed for this ADR accordingly.
There was a problem hiding this comment.
I think this line is still worth updating to say that both JWT and Session auth are okay but other deprectaed authentication schemes such as bearer are not. What do you think. That way this aligns with the cleanup we want to do.
|
@feanil: You should review openedx/edx-drf-extensions#284 and all its comments to see if you are missing anything, and you may want to reference it in this ADR. |
Faraz32123
force-pushed
the
docs/ADR-standardize_authentication_patterns_and_security_scheme_usage
branch
2 times, most recently
from
7504911 to
0ed80d7
Compare
robrap
left a comment
robrap
left a comment
There was a problem hiding this comment.
Additional thoughts. Thanks.
| @@ -0,0 +1,196 @@ | |||
| Standardize Authentication Patterns and Security Schemes | |||
| ======================================================== | |||
There was a problem hiding this comment.
Other auth ADRs (0003, 0008, 0009, 0010, 0013, 0014) live under openedx/core/djangoapps/oauth_dispatch/docs/decisions/. Add a pointer file there linking to this one.
|
|
||
| 1. **JWT authentication via** ``JwtAuthentication`` **MUST be the standard | ||
| authentication mechanism for all API(external and internal) access**, per `OEP-0042`_ | ||
| 2. **Session authentication MUST also be used when** the expected client for an API |
There was a problem hiding this comment.
"For all API access" would include admin views, /oauth2/access_token/, and HMAC/webhook endpoints — none of which use JwtAuthentication. Narrow this to "DRF API endpoints that take user-authenticated requests" and list the exclusions for context.
There was a problem hiding this comment.
@feanil: Would another way to say user-authenticated requests be password-authenticated or user-password-authenticated? I wasn't clear at first.
As an aside, for Mobile Authentication, there were some endpoints that will accept JwtAuthentication only if it has grant type password.
| authentication_classes = ( | ||
| JwtAuthentication, | ||
| SessionAuthenticationAllowInactiveUser, | ||
| ) |
There was a problem hiding this comment.
I think the target state should be not overriding the platform Defaults set in the settings files.
There was a problem hiding this comment.
SessionAuthentication and SessionAuthenticationAllowInactiveUser are different. If an endpoint only need JwtAuthentication & SessionAuthentication, then there's no need to add authentication_classes in an endpoint. What do u think?
There was a problem hiding this comment.
hmm, ok, yes for places that are currently using SessionAuthenticationAllowInactiveUser we'll need to leave them as is as that would be a breaking change, we'll need to deal with that later. That's fine.
Faraz32123
force-pushed
the
docs/ADR-standardize_authentication_patterns_and_security_scheme_usage
branch
from
03f1004 to
4d6afa4
Compare
Faraz32123
force-pushed
the
docs/ADRs-axim_api_improvements
branch
2 times, most recently
from
adf2e7b to
ad4b7ba
Compare
Move BearerAuthentication depr plan out of this doc So that it resides in single place i.e. to its deprecation ticket.
Faraz32123
force-pushed
the
docs/ADR-standardize_authentication_patterns_and_security_scheme_usage
branch
from
9ad4526 to
6c35624
Compare
5 participants
related issue: #38169