add 'aud' claim to align with ASTM oauth2 ? requested by industry

nasa / utm-apis

The collection of APIs for NASA's UTM project in the form of OpenAPI documents.

55 stars 35 forks source link

add 'aud' claim to align with ASTM oauth2 ? requested by industry #178

Closed issmith1 closed 4 years ago

issmith1 commented 4 years ago

The ASTM spec does not require 'aud'.
https://github.com/astm-utm/Protocol/blob/master/utm.yaml#L66

Upon receipt of a token, DSS requires 'aud' claim. If missing the token DSS will reject the token. As per MAAP meeting jun16 Chris asked DSS to relax and industry's reply was no; it must comply with oauth2 standard.

Assigning to Joey as I don't have his stance on this. The MAAP meeting on 10a june 23 will discuss further.

@arkits

RFC https://tools.ietf.org/html/rfc6749 Any specification that uses the authorization process as a form of delegated end-user authentication to the client (e.g., third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms that would enable the client to determine if the access token was issued for its use (e.g., audience-restricting the access token).

nasajoey commented 4 years ago

Sounds good @issmith1 . We'll coordinate with FAA to ensure our implementations are equivalent based on discussions with stakeholders. When we get a concrete answer I will likely document here and then hand back off to @arkits for implementation.

nasajoey commented 4 years ago

@issmith1, related to your quote of RFC6749, we are not using any implicit flow for USS-USS or USS-DSS, so I don't think that is directly applicable. Note that it may still be reasonable to use aud, but not due to that particular passage from the RFC. Please correct me if I am mistaken.

issmith1 commented 4 years ago

I clarified my meeting notes which claim the ASTM spec requires aud.

https://github.com/astm-utm/Protocol/blob/master/utm.yaml#L66 Also on L73 aud is mentioned.

nasajoey commented 4 years ago

Hmmm... if that is their DSS API it doesn't seem to make aud a requirement. Looks like a suggestion.

arkits commented 4 years ago

Noting down a few thoughts -

FIMS-AZ's API will need to be updated to integrate this. The token requester will need a way to specify who the audience of the token is. First thought is to add another required field to support this. For example -
```
grant_type=client_credentials&
client_id=uss_a&
scope=example.scope.read&
aud=uss_b
```
For USS to DSS communication, the aud must be something generic such as discovery, rather than dss_host_a. One of the concepts behind the DSS is that the data would become available to all DSS instances within the network to be support federated access. While there are no specifics, it seems reasonable enough to use the same token to talk to any DSS instance, no matter who the actual host is.

issmith1 commented 4 years ago

https://utm.arc.nasa.gov/docs/2019-UTM_Framework-NASA-TM220364.pdf UFAA section A1.4 declines use of 'aud' but recognizes its role in the future.

nasajoey commented 4 years ago

Based on discussions with FAA and UPP2 participants, we will support the aud claim. Updating the API to mach this understanding.

nasajoey commented 4 years ago

USS partners indicated that they will use the URL of the server that is targeted for use with the access token as the value for aud.

Authorization server may not implement more than syntactic validation of the audience request. The requirement for ensuring that the correct aud claim is provided in a token will be on the USSs and DSS to determine.

In the future, as requirements are further developed, the authorization server API may evolve to more requirements on valid values for the aud claim and request.