We've already discussed this, but didn't come to a conclusion.
There's two separate use-cases to consider:
1. Authentication
2. Offline access
For simplicity the examples below assumes OpenID Connect, but same logic applies to SAML.
Authentication
--------------
In this case user authenticates using an external IdP. After the user has authenticated
the access and refresh (if available) tokens are stored in user session. Tokens are
automatically refreshed by Keycloak to support brokered log out. In this case an
application can only retrieve an access token for the identity provider that was used to
authenticate the user.
Offline access
--------------
In this case we should add the option "offline access" to the provider config.
When enabled we add "offline" to the requested scope. When a user first logs in
or links through account mngmt we store the refresh token (aka "offline token")
in the user store. As this is a long term token I don't see any problems using the
user store for it. In this case an application can retrieve an access token for the
identity provider that was used to authenticate the user, but also for an identity
providers what have "offline access" enabled and there's an token store in
the user store. One issue with this approach is that brokered log out doesn't work. A
potential solution to that is that we only request offline access when linking the
account, but during authentication don't add the offline scope and use the process
from the first use-case.
Token retrieval
---------------
We add a "token service" client to Keycloak that has a "retrieve
token" role for each provider. For an application to be able to retrieve the token
the user has to have a role mapping on this role and the client has to have a scope on it
as well. This results in using standard roles, scopes and consent screens instead of a
different mechanism.
For 1.2.0 we should only add support for the "Authentication" use case. I
believe we pretty much already have this as Bill did this to support brokered log out.
Only thing we need to change is how we manage if a client has access to retrieve the token
or not. We should just jira the other use-case and add if it's requested by users.