# OAuth2 Application Listing

A feature of some other IDM systems is to also double as a portal to linked applications. This
allows a convenient access point for users to discover and access linked applications without having
to navigate to them manually. This naturally works quite well since it means that the user is
already authenticated, and the IDM becomes the single "gateway" to accessing other applications.

## How it should look

- The user should ONLY see a list of applications they _can_ access
- The user should see a list of applications with "friendly" display names
- The list of applications _may_ have an icon/logo
- Clicking the application should take them to the location

## Access Control

The current design of the OAuth2 resource servers (oauth2rs) is modeled around what the OAuth2
protocol requires. This defines that in an OAuth2 request, all of the requested scopes need be
granted else it can not proceed. The current design is:

- scope maps - a relation of groups to the set of scopes that they grant
- implicit scopes - a set of scopes granted to all persons

While this works well for the OAuth2 authorisation design, it doesn't work well from the kanidm side
for managing _our_ knowledge of who is granted access to the application.

In order to limit who can see what applications we will need a new method to define who is allowed
access to the resource server on the Kanidm side, while also preserving OAuth2 semantics.

To fix this the current definition of scopes on OAuth2 resource servers need to change.

- access scopes - a list of scopes (similar to implicit) that are used by the resource server for
  granting access to the resource.
- access members - a list of groups that are granted access
- supplementary scopes - definitions of scope maps that grant scopes which are not access related,
  but may provide extra details for the account using the resource

By changing to this method this removes the arbitrary implicit scope/scope map rules, and clearly
defines the set of scopes that grant access to the application, while also allow extended scopes to
be sent that can attenuate the application behaviour. This also allows the access members reference
to be used to generate knowledge on the kanidm side of "who can access this OAuth2 resource". This
can be used to limit the listed applications to these OAuth2 applications. In addition we can then
use these access members to create access controls to strictly limit who can see what OAuth2
applications to the admins of OAuth2 applications, and the users of them.

To support this, we should allow dynamic groups to be created so that the 'implicit scope' behaviour
which allow all persons to access an application can be emulated by making all persons a member of
access members.

Migration of the current scopes and implicit scopes is likely not possible with this change, so we
may have to delete these which will require admins to re-configure these permissions, but that is a
better option than allowing "too much" access.

## Display Names / Logos

Display names already exist.

Logos will require upload and storage. A binary type exists in the db that can be used for storing
blobs, or we could store something like svg. I think it's too risky to "validate" images in these
uploads, so we could just store the blob and display it?
