You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I expect that by moving constants like this into configuration files, oauth-ssh could accept tokens from other issues with different namespaces. Alternatively, we could specify an (xsede.org?) namespace that multiple issuers could support.
The text was updated successfully, but these errors were encountered:
That's for creating this issue. I completely agree that other tokens relying on RFC 7662 for introspection should be supported. We've dealt with this within another project where we supported custom prefixes for the tokens globus:<opaque>, which isn't in the spirit of RFC 7662 but deals with the practical issue of determining the issuer of an opaque token. The simpler alternative is to use a try-fail approach through a set of RFC 7662 introspection endpoints. I would suggest articulating the scopes along with the introspection endpoints, which would cover both mechanisms.
Feature request: Support RFC 7662 tokens from open source issuers (e.g., https://github.com/indigo-iam)
I think currently only tokens from globus.org are accepted. For example, the "https://auth.globus.org/scopes/" namespace appears to be hard-coded:
oauth-ssh/server/src/pam/pam.c
Line 183 in 2188e52
I expect that by moving constants like this into configuration files, oauth-ssh could accept tokens from other issues with different namespaces. Alternatively, we could specify an (xsede.org?) namespace that multiple issuers could support.
The text was updated successfully, but these errors were encountered: