Technologies
Vous êtes perdu entre autorisation et authentification ? Vous n'êtes pas seul. Consultez les informations suivantes pour en savoir plus sur la terminologie spécifique, les processus et les technologies employés lorsque vous utilisez IBM Cloud® App ID.
OAuth 2
OAuth 2.0 est un protocole standard ouvert utilisé pour autoriser les applications.
OIDC (Open ID Connect)
OIDC est une couche d'authentification qui fonctionne avec OAuth 2. Lorsque vous utilisez OIDC et App ID ensemble, vos données d'identification d'application permettent de configurer vos nœuds finaux de protocole d'autorisation OAuth. Si vous utilisez le logiciel SDK, les URL des noeuds finaux sont générées automatiquement. Toutefois, vous pouvez aussi les générer vous-même en utilisant vos données d'identification du service. L'URL est au format suivant : noeud final du service App ID + "/oauth/v4" + /ID titulaire.
Exemple :
{
"clientId": "7eba72ef-b913-47b0-b3b6-54358bb69035",
"tenantId": "8f5aa500-357e-443a-aab6-bf878f852b5a",
"secret": "OWEzZGM4M2UtZjhlYS00MDI2LTkwNGItNDJmYzViMmU2YzIz",
"name": "testing",
"oAuthServerUrl": "https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a",
"profilesUrl": "https://us-south.appid.cloud.ibm.com",
"discoveryEndpoint": "https://us-south.appid.ibm.cloud.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a/.well-known/openid-configuration"
}
D'après cet exemple, l'URL sera https://us-south.appid.cloud.ibm.com/oauth/v4/8f5aa500-357e-443a-aab6-bf878f852b5a. Vous y ajouterez ensuite le noeud final auquel vous voulez envoyer une demande. Consultez le tableau suivant pour
quelques exemples de noeud final.
| Noeud final | Format |
|---|---|
| Autorisation | <oauthServerUrl>/authorization |
| Jeton | <oauthServerUrl>/token |
| Informations utilisateur | <oauthServerUrl>/userinfo |
| JWKS | <oauthServerUrl>/publickeys |
Lorsque vous utilisez le logiciel SDK, les URL des noeuds finaux sont générées automatiquement.
Jetons
Le service utilise trois types de jeton différents. Les jetons sont définis dans Fournisseurs d'identité > Gérer du tableau de bord App ID. Pour plus d'informations sur les jetons et leur utilisation dans App ID, voir Gestion des jetons.
-
Jetons d'accès: Représenter l'autorisation et activer la communication avec desRessources protégées de back-end. Les ressources sont protégées par des filtres d'autorisation définis par App ID.
-
Jetons d'identité : représentent l'authentification et contiennent des informations concernant l'utilisateur.
-
Jetons d'actualisation : peuvent être utilisés pour obtenir un nouveau jeton d'accès sans nouvelle authentification de l'utilisateur. A l'aide des jetons d'actualisation, les utilisateurs peuvent autoriser l'application à mémoriser leurs informations, ce qui signifie qu'ils peuvent rester connectés.
En-têtes d'autorisation
App ID est conforme à la spécification relative aux jetons de support et utilise une combinaison de jetons d'accès et d'identité qui sont envoyés en tant qu'en-tête d'autorisation HTTP. L'en-tête d'autorisation se compose de trois parties distinctes séparées par un espace. Les jetons sont codés en Base64. Le jeton d'identité est facultatif.
Exemple :
Authorization=Bearer <accessToken> [<idToken>]
Stratégie d'API
La stratégie d'API s'attend à ce que les demandes contiennent un en-tête d'autorisation avec un jeton d'accès valide. La demande peut également contenir un jeton d'identité, mais cela n'est pas obligatoire. Si un jeton n'est pas valide ou a expiré, la stratégie d'API renvoie une erreur HTTP 401 qui contient l'en-tête HTTP suivant :
Www-Authenticate=Bearer scope="<scope>" error="<error>"
Si la demande renvoie un jeton valide, le contrôle passe au middleware suivant et la propriété appIdAuthorizationContext est injectée dans l'objet de la demande. Cette propriété contient les jetons d'accès et d'identité originaux,
ainsi que les informations de contenu décodées sous forme d'objets JSON ordinaires.
Stratégie d'application Web
Lorsque la stratégie d'application Web détecte des tentatives non autorisées d'accès à une ressource protégée, elle redirige automatiquement le navigateur de l'utilisateur vers la page d'authentification, qui peut être fournie par App ID. Si
l'authentification aboutit, l'utilisateur est ramené à l'URL de rappel de l'application Web. La stratégie d'application Web obtient des jetons d'accès et d'identité et les stocke dans une session HTTP sous WebAppStrategy.AUTH_CONTEXT.
Il revient à l'utilisateur de décider de stocker ou non les jetons d'accès et d'identité dans la base de données de l'application.
URI de redirection
App ID utilise une liste d'URI qualifiés complet approuvés pour rediriger vos utilisateurs après une interaction avec votre application. Par exemple, lorsque l'utilisateur a réussi à se connecter, App ID le redirige vers la page d'accueil de votre application ou toute autre page que vous avez désignée. Le format de votre URI peut changer en fonction de votre application. Pour plus d'informations, voir Ajout d'URI de redirection.
Jeu de clés Web JSON (JWKS)
Un JWKS représente un ensemble de clés cryptographiques. App ID utilise un JWKS pour vérifier l'authenticité des jetons générés par le service. En utilisant l'ID clé pour vérifier la signature, nous pouvons vous assurer que le jeton a été émis par une source sécurisée- App ID. Nous pouvons également vous assurer que les informations dans le jeton n'ont jamais été modifiées.