Configuration d'OAuth

Définissez la durée (en secondes) pendant laquelle le jeton d'accès associé à l'application confidentielle reste valide.

Cochez cette case pour utiliser le jeton d'actualisation que vous voulez obtenir lorsque vous utilisez les types d'octroi Propriétaire de ressource, Code d'autorisation et Assertion.

Définissez la durée (en secondes) pendant laquelle le jeton d'actualisation, renvoyé avec le jeton d'accès et associé à l'application confidentielle, reste valide.

Entrez le destinataire principal sur lequel le jeton d'accès de votre application confidentielle est traité.

Entrez les destinataires secondaires pour lesquels le jeton d'accès de votre application confidentielle est traité, puis sélectionnez Ajouter. Le destinataire secondaire apparaît dans la colonne de public secondaire, et la colonne de protégé permet de savoir si le public secondaire est protégé.

Pour spécifier les parties d'autres applications auxquelles votre application doit accéder, ajoutez ces portées à l'application confidentielle.

Les applications doivent interagir de manière sécurisée avec les applications confidentielles ou partenaires externes. En outre, les applications d'un service Oracle Cloud doivent interagir de manière sécurisée avec les applications d'un autre service Oracle Cloud. Chaque application possède des portées qui déterminent ses ressources disponibles pour d'autres applications.

A utiliser lorsque la portée d'autorisation est limitée aux ressources protégées sous le contrôle du client, ou aux ressources protégées inscrites auprès du serveur d'autorisation.

Le client présente ses propres informations d'identification pour obtenir un jeton d'accès. Ce jeton d'accès est associé aux propres ressources du client et non à un propriétaire de ressource particulier, ou à un propriétaire de ressource pour le compte duquel le client est autorisé à agir autrement.

A utiliser lorsque vous souhaitez vous appuyer sur une relation d'approbation existante exprimée en tant qu'assertion et sans étape d'approbation directe de l'utilisateur sur le serveur d'autorisation.

Le client demande un jeton d'accès en fournissant une assertion JWT (jeton Web JSON) utilisateur ou une assertion JWT utilisateur tierce, et des informations d'identification client. Une assertion Jeton est un package d'informations qui facilite le partage d'informations d'identité et de sécurité entre des domaines.

A utiliser lorsque vous souhaitez vous appuyer sur une relation d'approbation existante exprimée en tant qu'assertion SAML2 et sans étape d'approbation directe de l'utilisateur sur le serveur d'autorisation.

Le client demande un jeton d'accès en fournissant une assertion SAML2 utilisateur ou une assertion SAML2 utilisateur tierce, et des informations d'identification client. Une assertion SAML2 est un package d'informations qui facilite le partage d'informations d'identité et de sécurité entre des domaine de sécurité.

Sélectionnez ce type d'octroi pour obtenir un code à l'aide d'un serveur d'autorisation faisant office d'intermédiaire entre l'application client et le propriétaire de la ressource.

Un code d'autorisation est renvoyé au client via un réacheminement de navigateur une fois que les propriétaires de la ressource ont donné leur consentement au serveur d'autorisation. Le client échange ensuite le code d'autorisation avec un jeton d'accès (et souvent d'actualisation). Les informations d'identification du propriétaire de la ressource ne sont jamais exposées au client.

Si l'application ne peut pas maintenir les renseignements d'identification client confidentiels lors de l'authentification auprès de la serveur d'autorisation. Par exemple, votre application est implémentée dans un navigateur Web à l'aide d'un langage de script tel que JavaScript. Un jeton d'accès est renvoyé au client via un réacheminement de navigateur en réponse à la demande d'autorisation du propriétaire de la ressource (plutôt qu'une autorisation intermédiaire).

Sélectionnez le type d'octroi Code de l'ordinateur si le client n'est pas en charge de recevoir des demandes du serveur d'autorisation OAuth, par exemple, lorsqu'il ne peut plus agir comme un serveur HTTP (consoles de jeu, lecteurs multimédias de transmission en continu, cadres numériques, etc.).

Dans ce flux, le client obtient le code utilisateur, le code de l'appareil et l'URL de vérification. L'utilisateur accède ensuite à l'URL de vérification dans un navigateur distinct pour approuver la demande d'accès. C'est uniquement à ce moment-là que le client peut obtenir le jeton d'accès à l'aide du code de l'appareil.

Sélectionnez le type d'octroi Authentification du client TLS afin d'utiliser le certificat client pour l'authentification auprès du client. If a token request comes with an X.509 client certificate and the requested client is configured with the TLS Client Authentication grant type, the OAuth service uses the Client_ID in the request to identify the client and validate the client certificate with the certificate in the client configuration. Le client est authentifié uniquement si les deux valeurs concordent.

Pour renforcer le niveau de sécurité, avant d'activer le type d'octroi Authentification du client TLS, activez et configurez la validation OCSP, et importez un certificat du partenaire sécurisé.

Cochez cette case si vous souhaitez utiliser des URL HTTP pour les champs URL du réacheminement, URL du réacheminement ou URL du réacheminement après déconnexion. Par exemple, pour envoyer des demandes en interne, pour utiliser une communication non cryptée ou pour assurer la compatibilité amont avec OAuth 1.0, vous pouvez utiliser une URL HTTP.

Cochez également cette case lorsque vous développez ou testez votre application et que vous n'êtes pas sûr d'avoir configuré SSL. Cette option n'est pas recommandée pour les déploiements de production.

Entrez l'URL d'application vers laquelle l'utilisateur est réacheminé après l'authentification.

Remarque : Fournissez une URL absolue. Les URL relatives ne sont pas prises en charge.

Entrez l'URL vers laquelle vous voulez réacheminer l'utilisateur après qu'il s'est déconnecté de l'application.

Entrez l'URL vers laquelle l'utilisateur est réacheminé après s'être déconnecté de l'application confidentielle.

Sélectionnez le type de client. Les types client disponibles sont Sécurisé et Confidentiel. Sélectionnez Sécurisé si le client peut générer les assertions utilisateur auto-signées. Ensuite, pour importer la signature de certificat que le client utilise pour signer son assertion auto-signée, sélectionnez Importer le certificat.

Sélectionnez l'un des algorithmes de cryptage de contenu.

Si cette option est activée, cet attribut remplace l'attribut Exiger un consentement sur toutes les portées configurées pour l'application, et aucune portée ne nécessite de consentement.

Sélectionnez l'une des options suivantes pour permettre à l'application client d'accéder aux ressources autorisées :

• Tout : permet d'accéder à n'importe quelle ressource d'un domaine (tout). Reportez-vous à Accès à toutes les ressources.

• Spécifique : permet d'accéder uniquement aux ressources dont il existe une association explicite entre le client et la ressource (spécifique). Reportez-vous à Accès aux ressources avec des portées spécifiques.

Remarque : L'option permettant de définir une ressource autorisée est disponible uniquement pour les applications confidentielles. Le périmètre de sécurisation ne peut pas être défini pour les applications mobiles.

Si vous voulez que l'application accède aux API d'autres applications, sélectionnez Ajouter les ressources dans la section Stratégie d'émission de jetons. Ensuite, dans la fenêtre Ajouter un champ d'application, sélectionnez les applications que votre application référence.

Remarque : vous pouvez supprimer des portées en sélectionnant l'icône x en regard de la portée. En revanche, vous ne pouvez pas supprimer les portées protégées.

Sélectionnez Ajouter des rôles d'application. Dans la fenêtre d'ajout de rôles d'application, sélectionnez les rôles d'application à affecter à l'application. Votre application peut ainsi accéder aux API REST auxquelles chacun des rôles d'application affectés peut accéder.

Par exemple, sélectionnez Administrateur de domaine d'identité dans la liste. Toutes les tâches d'API REST disponibles pour l'administrateur de domaine d'identité sont accessibles pour votre application.

Vous pouvez supprimer les rôles d'application en le sélectionnant, puis en sélectionnant Enlever.

Remarque : vous ne pouvez pas supprimer des rôles d'application protégés.