Discovering allowed Resource App (instances) for the logged in user

[dlozlla]

As raised in issue #51, a seamless user experience requires that Requesting Apps have a way to discover which applications, and their specific instances, a user is allowed to access. This would allow mirroring the experience of SSO dashboards, where users can simply select the app instance they want to use.

This raises several questions:

• Should the IdP expose an "Accessible Resources API" to list the available Resource Apps and their instances for an authenticated user?
• How should such an API structure its data to clearly differentiate between multiple instances of the same application?
• Should this API be standardized?

[meghnadubey]

While the need for this API may be generic, the schema will be specific to the particular IdP implementation of IdAssertion Authz Grant setup and will be difficult to standardize.
The API for any IdP will depend on how it is facilitating the setting up of secure "virtual connection" between requesting instances and resource instances, for the IT Admin. So this API is basically a form of get connections API that supports intuitive search for a particular app, and most likely this API schema in some form will be part of any IdP implementation.
We can definitely set up a recommendation, but I'm skeptical upon the practicality of standardizing it.

[mcguinness]

I think this would be a better fit for a new OIDC defined protected resource to complement /userinfo for an OP to publish the SSO apps and resources for a user than something this spec should define. This would be be similar to something like https://developer.okta.com/docs/api/openapi/okta-myaccount/myaccount/tag/OktaApplications/#tag/OktaApplications/operation/listOktaApplications or https://developer.okta.com/docs/api/openapi/okta-management/management/tag/UserResources/#tag/UserResources/operation/listAppLinks that enables a client to dynamically construct a SSO dashboards/etc. I would not expect this any OAuth specs.

The connect-ab working group would be a good place to signal from other OIDC providers if this is valuable

[mcguinness]

Ignoring SAML, is this in the right direction of what an OP should provide?

GET /sso/trusted_clients
Host: idp.example
Authorization: Bearer <access_token>

HTTP/1.1 200 OK
Content-Type: application/json

[
  {
      "client_id": "123",
      "client_name": "Wiki SaaS App",
      "client_uri": "https://app.wiki.example",
      "logo_uri": "https://app.wiki.example",
      "initiate_login_uri": "https://idp.example/launch/123"
  }
]

GET /sso/trusted_authorization_servers
Host: idp.example
Authorization: Bearer <access_token>

HTTP/1.1 200 OK
Content-Type: application/json

[
  {
      "authorization_server_id": "https://as.chat.example",
      "authorization_server_name": "Chat Authorization Server",
      "client_id": "example.wiki.app"
      "resources": [
          {
              "resource_id": "https://api.chat.example",
              "resource_name": "Chat API"
              "scopes_supported": [
                  "api:read",
                  "api:write"
              ]
          }
      ]
  }
]

[meghnadubey]

Ignoring SAML, is this in the right direction of what an OP should provide?

GET /sso/trusted_clients
Host: idp.example
Authorization: Bearer <access_token>

HTTP/1.1 200 OK
Content-Type: application/json

[
{
"client_id": "123",
"client_name": "Wiki SaaS App",
"client_uri": "https://app.wiki.example",
"logo_uri": "https://app.wiki.example",
"initiate_login_uri": "https://idp.example/launch/123"
}
]
GET /sso/trusted_authorization_servers
Host: idp.example
Authorization: Bearer <access_token>

HTTP/1.1 200 OK
Content-Type: application/json

[
{
"authorization_server_id": "https://as.chat.example",
"authorization_server_name": "Chat Authorization Server",
"client_id": "example.wiki.app"
"resources": [
{
"resource_id": "https://api.chat.example",
"resource_name": "Chat API"
"scopes_supported": [
"api:read",
"api:write"
]
}
]
}
]

This seems like a good starting point for id_assertion_authorization_provider_metadata discovery. The two endpoints provide a list of available clients, and a list of available resources for these clients. The latter can support multiple resource_ids for the same authz_server_id, and possibly other interesting metadata about the resource such as domain(environment) which can hep distinguish between these resource_ids, since scope may overlap.

[mcguinness]

My thoughts for SAML was that it would solve a lot of problems and simplify things if the requesting app converted the SAML Assertion to a Refresh Token and obtained an id_token and access_token (see #48 (comment)).

The client could then use the access token to discover OAuth/OIDC OP metadata such as the example above.

[sdesen]

converted the SAML Assertion to a Refresh Token

Similarly, can a SAML assertion be converted to an id_token using saml2-bearer?

Also, related to the trusted clients/accessible resources endpoint, I think what @mcguinness showed as example responses were what we were thinking. The client_id + sub from the token passed in the Authorization header will be important context for the endpoint. We discussed the authentication fro that endpoint actually including the id_token instead of the access_token, and I think the only thing it would include over the access token is the session_id. If its not needed, the id_token doesnt need to be send in the request 🤔

[mcguinness]

I don’t recommend using https://www.rfc-editor.org/rfc/rfc7522 to obtain an ID Token. The assertion is intended to only be used to obtain an access token only and interoperability only defines how delegated authorization should work cross domain. There is also very limited use of this grant in the wild today.

[aaronpk]

This is what I am thinking for the new endpoint.

The input to the request is the client authentication and the user's subject token.

The response is the information needed to use in a Token Exchange request: audience and resource.

POST /xaa/configured_resources
Host: idp.example
Authorization: <HTTP Basic Auth or PKJWT> [Client's Authentication]

subject_token=User's ID Token that would have been sent to the Token Exchange request


HTTP/1.1 200 OK
Content-Type: application/json

[
  {
      "audience": "https://resource-as-issuer-url", (REQUIRED),
      "resource": "123", (OPTIONAL),
      "scope": "read write", (OPTIONAL)
  }
]

[meghnadubey]

This is a good starting point for a standard endpoint, not specific to internal IdP implementation. The json keys are also the same as in id-jag request and jwt, making these unambiguous.

[mcguinness]

@aaronpk suggestion fits a more IETF style endpoint that complements ID-JAG and Token Exchange. I would expect this endpoint to be a IETF draft as it would work with any subject token type (needs subject_token_type as input param) just like revocation endpoint or token exchange endpoint.

The other approach is to follow UserInfo as a protected resource in OIDC which would use an access token and a scope which #52 (comment) was suggesting. This would be more IdP centric and could provide other SSO resources such as App Links.

Which path do we want?

[aaronpk]

My thought was to not introduce a new token, and just leverage the existing artifacts we already have. (Since access tokens are not currently used in the Cross App Access exchange)

Going the “Userinfo” route we would need to also ensure the IdP returns an access token during SSO that can be used for this. This also implies there should be a scope defined for the client to request the ability to make this query.

[mcguinness]

I was making assumption that majority of real world scenarios will need a Refresh Token so obtaining an Access Token for the IdP wouldn't be a challenge but I see value in a minimum surface area endpoint. Happy to spec the IETF style endpoint in a new draft.

[sdesen]

Should issuer as the authz issuer that is trusted not be included in each resource object?
Edit: ah, i see this is the audience in aarons proposal.