Skip to content
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

[dannym-refactor] Location of Authorization Server Metadata #8

Closed
garethsb opened this issue Jan 22, 2020 · 3 comments
Closed

[dannym-refactor] Location of Authorization Server Metadata #8

garethsb opened this issue Jan 22, 2020 · 3 comments

Comments

@garethsb
Copy link
Contributor

The current goal is to align IS-10 with RFC 8414, and as such support the method defined in RFC 8414 Section 3 for discovery of the server endpoints.

The current RAML adds a /.well-known/oauth-authorization-server endpoint. However, that is relative to the base URL defined in the RAML which is /x-nmos/auth/{version}.

I wondered if the intent was to have a top-level /.well-known/oauth-authorization-server endpoint that redirected to the one defined in the RAM L, but I can't see that RFC 8414 (or RFC 5785) allow a redirect response, suggesting only 200 OK for a successful response?

(I'm also not clear as to the use-cases for RFC 8414 multiple issuers on a host, which it describes in section 3.1, resulting in the well-known URL request being to https://api.example.com/.well-known/oauth-authorization-server/{issuer} instead. Can you explain?)

@dannymeloy
Copy link
Contributor

Hi Gareth,

  1. The RAML is currently mistaken - the /.well-known/.. endpoint will hang off the the root path (e.g. https://{host}:{port}/.well-known/oauth-authorization-server.)
  2. With regards to both versioning of the well-known endpoint (mentioned in issue [dannym-refactor] Relationship between DNS-SD discovery and RFC 8414 approach #9) and multiple issuers on the same host, the thinking currently is that we define another text record in the DNS-SD announcement (call it issuer_path.), for a given auth server instance, that defines the {issuer} tag in the .well-known url. This will usually be blank or omitted, meaning clients default to the URL you have given above.
    If multiple auth services are hosted on the same host, or if integrating with an Off-the-Shelf auth server with a metadata URL with a different {issuer}, this issuer_path record can distinguish/point-at the auth server instances. From an NMOS perspective, this record could also give clients distinct server metadata URLs for different versions if we needed to - using two DNS-SD records with different text records. In this case, both the api_ver and issuer_path records may both be equal to v1.1 for example.

I hope that makes sense...

@garethsb
Copy link
Contributor Author

Thanks, that does start making sense. I think it's going to be simpler to document the /.well-known/ URL via separate means, whether that's pure documentation or a separate RAML file.

@NEOAdvancedTechnology
Copy link
Contributor

worked out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants