Higher level clients add `openid` scope, whereas low level ones don't, potentially causing `REQUIRED_IDENTITY_MISSING`

[multimeric]

The higher level ClientApp adds openid as a default scope. This doesn't seem to be documented on the class:

globus-sdk-python/src/globus_sdk/globus_app/client_app.py

Lines 48 to 49 in c8f27b8

	:param scope_requirements: A mapping of resource server to initial scope
	requirements.

Also, seemingly you can't even stop it doing that:

>>> globus_sdk.ClientApp(client_id=..., client_secret=...).scope_requirements
>>> {'auth.globus.org': [Scope('openid')]}
>>> globus_sdk.ClientApp(client_id=..., client_secret=..., scope_requirements={}).scope_requirements
{'auth.globus.org': [Scope('openid')]}
>>> globus_sdk.ClientApp(client_id=..., client_secret=..., scope_requirements={globus_sdk.scopes.TransferScopes.resource_server: globus_sdk.scopes.TransferScopes.all}).scope_requirements
{'transfer.api.globus.org': [Scope('urn:globus:auth:scope:transfer.api.globus.org:all')], 'auth.globus.org': [Scope('openid')]}

On the other hand, the lower level globus_sdk.ConfidentialAppAuthClient.oauth2_start_flow is documented as adding this scope by default.

globus-sdk-python/src/globus_sdk/services/auth/client/confidential_client.py

Lines 115 to 116 in c8f27b8

	:param requested_scopes: The scopes on the token(s) being requested. Defaults to
	``openid profile email urn:globus:auth:scope:transfer.api.globus.org:all``

Unlike ClientApp, you can override this by just passing in a custom scope:

globus_sdk.ConfidentialAppAuthClient(...).oauth2_start_flow(..., requested_scopes=...)

---

What this means is that if you pass the exact same scopes list to both of these objects, then the ConfidentialAppAuthClient will generate tokens that are not compatible with the ClientApp! This causes a confusing error AuthAPIError: ('POST', 'https://auth.globus.org/v2/oauth2/token', 'Basic', 403, 'REQUIRED_IDENTITY_MISSING', "In order to access 'APP NAME', you need to link an identity from ORG NAME to your account.", 'xxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx)

Some helpful changes might include:

• Documenting this openid behaviour in ClientApp
• Making the two clients consistent in whether they do or don't add openid scopes
• Add a ClientApp.clear_scope_requirements(). Currently I do ClientApp._scope_requirements = {} to remove the openid scope that I don't want
• Improve the error message when you have tokens that are valid but whose scopes are mismatched

[sirosen]

We definitely have some documentation issues here. Thanks for reporting!

1. We should document that GlobusApp instances always request an openid scope (more on why below)
2. oauth2_start_flow on the login client types no longer has a default. The documentation stating that it does have one is wrong.

---

Add a ClientApp.clear_scope_requirements(). Currently I do ClientApp._scope_requirements = {} to remove the openid scope that I don't want

I think the fact that this is a private attribute adequately indicates that you should not be doing this.

The openid scope is needed in order for the app to get back an id_token in the token response, as part of the OpenID Connect (OIDC) specification. That id_token is key to GlobusApp behaviors which guard against the user switching identities between login flows.

Switching identities accidentally (without an explicit logout) can create confusing scenarios in which your tokens are a mix of those for AccountA and AccountB. These scenarios are difficult to debug and manifest as inconsistent results between different services. GlobusApp doesn't allow for these sorts of invalid states, but in order to check and record the identity associated with login flow results, it needs the openid scope to be present.

The addition of the openid scope also guarantees that a login will result in a Globus Auth token, which the app uses to access the Globus Auth Consents API, to determine when logins are needed.

You can see where the scope is introduced, with an explanatory comment, here:

globus-sdk-python/src/globus_sdk/globus_app/app.py

Lines 145 to 152 in c8f27b8

	# finally, attach the app to the internal consent client
	# this needs to wait until the very end of the app initialization process so
	# that the authorizer factory is all ready to accept the client
	# registering its scope requirements
	#
	# additionally, this will ensure that openid scope requirement is always
	# registered (it's required for token identity validation).
	consent_client.attach_globus_app(self, app_scopes=[AuthScopes.openid])

I don't think there's a reason to allow users to remove the hardcoded openid scope. At least without a clearer motivating use case, I do not expect us to allow for such usage.

But we can and should document that GlobusApp logins will always request the openid scope, and this is expected behavior.

---

You are citing an error which you are seeing, but I'm actually a bit confused about how you are getting that error. You say

... if you pass the exact same scopes list to both of these objects, then the ConfidentialAppAuthClient will generate tokens that are not compatible with the ClientApp! This causes a confusing error ...

How are you using these two such that tokens from a direct use of the ConfidentialAppAuthClient are being seen by the ClientApp? I'm not clear on how the two are being mixed.

I have a suspicion, based on the error you report, that this is not really the cause of the error. The message you cite looks like an unmet required domain setting on a Globus Auth client registration. I may be mistaken, of course, since I can't tell from your report how these components are being combined.

[multimeric]

Thanks. In summary it seems that I should just add the openid scope to both clients rather than removing it from both. In this case, I wonder if oauth2_start_flow() should add this scope like GlobusApp does.

How are you using these two such that tokens from a direct use of the ConfidentialAppAuthClient are being seen by the ClientApp?

The broad logic is that I get the tokens using ConfidentialAppAuthClient directly and then I pass the tokens to ClientApp which lives in another module.

It may be the case that I'm doing something wrong, but I know that simply adding ClientApp._scope_requirements = {} did prevent the above error. I know this is not recommended but I couldn't find any easy fix involving a public interface.

The message you cite looks like an unmet required domain setting on a Globus Auth client registration

The app I'm using does indeed have a required domain setting, but the identity I'm testing it with does have this domain.

[sirosen]

Thanks. In summary it seems that I should just add the openid scope to both clients rather than removing it from both. In this case, I wonder if oauth2_start_flow() should add this scope like GlobusApp does.

You can add openid to your scopes, but it would not be correct for oauth2_start_flow to introduce it when it's not requested.
It's being added by GlobusApp -- the higher level of abstraction -- because it's needed at that layer. But it's perfectly valid to do a login flow without asking for the openid scope.

That might be the correct fix for you in your case, but I'm not comfortable recommending it to you yet because my expectations as a library maintainer are being violated here. There's something about your usage which is, basically, "surprising me", and I don't really want to make suggestions without understanding better.

... and then I pass the tokens to ClientApp which lives in another module.

How are you doing this? I can think of ways, but there isn't supposed to be an interface for passing tokens into a GlobusApp from the outside. GlobusApp is supposed to manage its own tokens.

It may be the case that I'm doing something wrong, but I know that simply adding ClientApp._scope_requirements = {} did prevent the above error. I know this is not recommended but I couldn't find any easy fix involving a public interface.

Yeah, I understand that that's making things work, at least for now, and that makes it attractive.
But my concern is that the fundamental mismatch is still there, and what's really happening is that you're suppressing the error, and it could come back and bite you later.

---

If there's a domain requirement, I think you need to be authenticating as a user in order for things to work correctly.

Are you sure you want to be using a ClientApp for your use case, rather than a UserApp initialized with your client credentials?
A UserApp can take both client_id and client_secret, and I suspect that might be the right fit for your use-case.

ClientApp is for authenticating as the client, not as a user. That could help explain why a missing requirement would lead to an error. ClientApp authentications are not using oauth2_start_flow, but rather to oauth2_client_credentials_tokens.

[multimeric]

I'm happy to elaborate on my implementation, but maybe not in this thread? Would you like me to file a support ticket or send it as an email somewhere? Then we can add our conclusions back to this thread.

[sirosen]

If you prefer, send us a support ticket via support@globus.org -- please include a link to this issue, as it will help whoever triages it route it correctly.

We're happy to discuss in either forum. But yes, as you seem to guess, we probably need a lot more detail about what your needs and usage look like. 😁