MONGOSH-1906 Add OIDC workforce auth requirements docs #1731
Conversation
…n) OIDC Auth For MongoDB
…n) OIDC Auth For MongoDB
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 advertise attacker-controlled IdP metadata and and intercept tokens intended for other clusters (or even other OIDC 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.
This section is pretty much entirely internal-facing, there isn't really anything secret or confidential in here, but it doesn't really apply to outside users
There was a problem hiding this comment.
I'm in favor of keeping this though, unless there is some other place we can put it. It's very useful info (for me).
docs/workforce-human-oidc-auth.md
Outdated
| 2. The HTTP server SHOULD set default headers of `Content-Security-Policy: default-src 'self'` and `Referrer-Policy: no-referrer`, or similarly restrictive defaults. | ||
| 3. Compose the URL for Auth Code Flow, using the code challenge generated earlier and the redirect URL from the previous step, with the port replaced with the actual port if it was specified as `0`. | ||
| 1. The application MUST add a `state` parameter containing cryptographically random data ([RFC6749](https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.1) specifies this as optional but recommended). | ||
| 2. The application MAY allow the user to indicate that it should add a `nonce` parameter containing cryptographically random data to the authentication request, as defined in the OpenID connect specification, which is then later embedded in the ID token itself. |
There was a problem hiding this comment.
This item is currently under active investigation, MONGOSH-1905 is essentially a user request for this, on the other hand we've had tickets like MONGOSH-1669 where we've been taking a stance where we don't strictly require OIDC features and are happy with OAuth-2.0-only features.
The text of the OIDC spec ("If present in the ID Token, Clients MUST verify that the nonce Claim Value is equal to the value of the nonce parameter sent in the Authentication Request.") does imply to me that the IdP cannot, on its own, add a nonce value that the client did not specify to begin with and still be considered spec-compliant.
Now ... maybe adding nonces is something that all relevant identity providers support anyway, in which case we're fine to turn this line into a SHOULD/MUST and remove the user interaction, but we'd likely need to verify this first. So that's why, for now, this is the wording I'm going with here.
addaleax
changed the title
Thank you @alexbevi for the support here 🙂