-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add oauth metadata discovery as per RFC8414 #81
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few inline comments. The biggest issue is how to build up the OAuth2 discovery path for multitenant hosts.
src/scitokens/utils/keycache.py
Outdated
response = request.urlopen(request.Request(meta_uri, headers=headers)) | ||
data = json.loads(response.read().decode('utf-8')) | ||
# https://tools.ietf.org/html/rfc8414 | ||
# We first try the RFC's metadata location, then try the openid defined |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, RFC8414 is more complex. To quote:
The client would make the following request when the
issuer identifier is "https://example.com/issuer1" and the well-known
URI suffix is "oauth-authorization-server" to obtain the metadata,
since the issuer identifier contains a path component:GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1 Host: example.com
Using path components enables supporting multiple issuers per host.
This is required in some multi-tenant hosting configurations. This
use of ".well-known" is for supporting multiple issuers per host;
unlike its use in RFC 5785 [RFC5785], it does not provide general
information about the host.
So for the RFC8414 case, you have to prepend .well-known/oauth-authorization-server
to the path while in OIDC you add it as a suffix.
Can you also make the ordering of the discovery (OIDC or OAuth2) something specified in the configuration file instead of embedded in the code?
src/scitokens/utils/keycache.py
Outdated
well_known_uri = [".well-known/oauth-authorization-server", ".well-known/openid-configuration"] | ||
last_exception = MissingIssuerException("Unable to retrieve public key from issuer") | ||
jwks_uri = None | ||
for uri in well_known_uri: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This code block is getting long. Since there is less commonality between OAuth2 and OIDC than thought, maybe make these into two separate subroutines?
@@ -100,6 +100,23 @@ def test_ec_deserialization(self): | |||
scitoken = scitokens.SciToken.deserialize(serialized_token, insecure=True) | |||
|
|||
|
|||
def test_failures(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also have a test for the RFC8414 style of discovery?
Addressed all the comments above. |
Fixes #75