Unity STS complies with The OAuth 2.0 Authorization Framework
Authorization Code Grant should be always the first choice, if suitable.
Implicit Grant should be used only by a public client (client not capable to keep a secret safely) such as Mobile apps or javascript apps.
Said so, target api should be user-centric and the working session should be limited.
Implicit grant has not been designed for accessing the user resources in the absence of the user: the access token should not be stored for later use.
Resource Owner Password Credentials Grant should be used where a very high trust-level exists between the client app and the authorization/resource server.
In case you decide to use this grant from a public client, your client app should leverage on its own backend server to obtain (server-side) a long-lived access token through the refresh token obtainied within the access token response (client-side).
The long-lived access token should be used only server 2 server: client app backend server calling the Unity SOA Services (resource server).
Client Credentials Grant apply only for those Unity SOA Services which the authentication is not user-related: the most common scenario are service apis to support a backoffice/backend app.
Unity STS complies with The OAuth 2.0 Authorization Framework: Bearer Token Usage
Full documentation: //components.uefa.com/UnitySTS/v1/api/metadata
Unity STS does not support a single token revocation.
User token(s) can be invalidated revoking its authorization(s) through the RevokeToken or
RevokeUserAuthorizations api.
In case two or more apps (for. ex. android acme app and iOS acme app) are sharing same client identifier(for. ex. acme-mobile-identifier), revoking a user token automatically implies that all apps, not just the one that explicitly revoked the token, will need to re-authenticate the user trough the sts.
In order to keep the authentication / token lifetime separeted, you need to request a single client identifier per each app (for. ex. acme-android-identifier and acme-ios-identifier).
We suggest to avoid token revocation if not strictly required.
The suggest behaviour is to request a short-lived token from the public client and refresh it through the related backend server, that should be able to keep the related client secret safely.
A client application token cannot be revoked: in order to make a client application token no longer suitable for api authorization, the application itself has to be deleted.