MONGOSH-1906 Add OIDC workforce auth requirements docs #1731
Conversation
…n) OIDC Auth For MongoDB
…n) OIDC Auth For MongoDB
addaleax
changed the title
Co-authored-by: Nikola Irinchev <[email protected]>
docs/workforce-human-oidc-auth.md
Outdated
| Currently, users who connect to a host other than localhost or an Atlas hostname need to explicitly opt-in into being | ||
| able to do so by setting the `ALLOWED_HOSTS` flag (specified in the drivers auth spec). In the future, MongoDB is hoping | ||
| to support Demonstrating Proof of Possession (DPoP, [RFC9449](https://datatracker.ietf.org/doc/html/rfc9449)) that will | ||
| allow lifting this restriction. The goal here is to prevent users from connecting to untrusted endpoints that will |
There was a problem hiding this comment.
I suggest omitting this forward-looking statement about implementing DPoP.
There was a problem hiding this comment.
I've moved these into an appendix section at the end of the file and cleaned them up a bit. I do think that these are items that implementers should be aware of, especially considering that "accidentally" implementing these may be counterproductive – depending on the OIDC library used, it may be quite easy to do so, but there would be a risk of doing it in a way that is incompatible with what we end up standardizing on in the future.
It's a good reminder, though. In particular RFC8707 adoption is essentially just a client-side thing that we need to figure out and shouldn't require server support, so I've opened https://jira.mongodb.org/browse/MONGOSH-1937 to make sure we do end up investigating this option.
docs/workforce-human-oidc-auth.md
Outdated
| endpoints in general). | ||
|
|
||
| We would also like to generally adopt [RFC8707](https://datatracker.ietf.org/doc/html/rfc8707), but have not decided on | ||
| a specific format for expressing the MongoDB endpoints as resources. |
There was a problem hiding this comment.
Same here as we may never implement this feature.
|
|
||
| - The scopes listed in the `requestScopes` field of the IdP response from the MongoDB endpoint, and | ||
| - The `openid` and `offline_access` scopes[^3]. If the IdP metadata document contains a `scopes_supported` field, and | ||
| this field does not list one of these scopes, then the respective scope SHOULD NOT be added to the `scope` |
There was a problem hiding this comment.
Is this a SHOULD NOT or a MUST NOT? Does auth fail if an unsupported scope is provided?
There was a problem hiding this comment.
Hm, yeah, it's a good question, and I've gone a bit back and forth on this in response to you bringing it up 🙂
I think the RFC2119 definition of "SHOULD NOT" is ultimately the right one here. The implementer would need to accept that their application's authentication attempts could be rejected by an IdP that doesn't provide refresh tokens (as that is what offline_access asks for). That seems like a sensible behavior for an application that strictly requires ongoing access to the cluster while it is active – e.g. mongosync might want to make this choice (Not saying they do, but that it would be understandable if they did).
That being said, if you feel strongly here, I'm still happy to make this change.
Does auth fail if an unsupported scope is provided?
It's up to the individual IdP (this sentence referring to the IdP/server side of OIDC):
Scope values used that are not understood by an implementation SHOULD be ignored.
Thank you @alexbevi for the support here 🙂