API Guide: update auth section on bearer tokens #11099
Conversation
suggested edits
pdurbin
changed the title
Co-authored-by: Philip Durbin <[email protected]>
| If properties are provided in the JSON, but corresponding claims already exist in the identity provider, an error will be thrown, outlining the conflicting properties. | ||
| The one parameter required by default is ``termsAccepted`` which must be set to true, indicating that the user has seen and accepted the Terms of Use of the installation. | ||
|
|
||
| If the feature flag ``api-bearer-auth-handle-tos-acceptance-in-idp`` is enabled (along with the ``api-bearer-auth`` feature flag), Dataverse assumes that the Terms of Service acceptance was handled by the identity provider, e.g. in the OIDC ``consent`` dialog, and the ``termsAccepted`` parameter is not needed. |
There was a problem hiding this comment.
@pdurbin: Could we do this?
"If the feature flag api-bearer-auth-handle-tos-acceptance-in-idp is enabled (along with the api-bearer-auth feature flag), Dataverse assumes that the Terms of Service acceptance is handled by the Identity Provider and therefore the ``termsAccepted'' parameter is not needed."
The current process is not true authentication. The system receives a token that may not be intended for it, and uses it to create an account without prompting. The real authentication takes place somewhere else, we assume the SPA, where hopefully the consent screen is used. With this formulation, the behaviour is less ambiguous, since Dataverse itself has no means of using a consent screen.
There was a problem hiding this comment.
This is a documentation PR trying to clarify what has already been implemented/merged in #10972.
If there's something to change other than tweaking language, it should probably be a new issue (which should probably be in the dataverse-security repo). FWIW: I could be wrong, but I don't believe that "The system receives a token that may not be intended for it, and uses it to create an account without prompting" is true - the received token is used to call the userinfo API of registered providers only, and only if one of them returns a valid userinfo response is an account created.
There was a problem hiding this comment.
FWIW: I could be wrong, but I don't believe that "The system receives a token that may not be intended for it, and uses it to create an account without prompting" is true - the received token is used to call the userinfo API of registered providers only, and only if one of them returns a valid userinfo response is an account created.
This scenario only applies if a third party has a valid token (which stays valid during the user info API calls) and send it without user consent to a dataverse instance. This is to be honest a malicious scenario, which most likely will not occur.
|
proof read, no issues found. merging pr |
This was a suggested edit for #10972 that I'm guessing wasn't seen before QA/merge.
Preview at https://dataverse-guide--11099.org.readthedocs.build/en/11099/api/auth.html#bearer-tokens