[JAVA] Procédure de création d'un serveur d'autorisation avec Authlete (version compatible CIBA)
Qu'est-ce que OAuth / OpenID Connect CIBA (Client Initiated Backchannel Authentication)?
Je suis allé au "Groupe d'étude OAuth & OIDC (Spécial FAPI & CIBA!)" qui s'est tenu le 28/03 (jeudi).
L'organisateur est Authlete, une société qui fournit des Baas capables de créer des serveurs d'autorisation OAuth et OpenID Connect (OIDC). Le service cloud Authlete était compatible avec CIBA, qui est une nouvelle spécification d'OAuth / OIDC, il s'agissait donc d'une session d'étude qui a également servi d'introduction au service cloud.
Mis à part mon OAuth, CIBA était mon premier regard, donc j'ai beaucoup appris. Merci aux gens d'Authlete qui ont accueilli la session d'étude.
Cette fois, il s'agissait de FAPI (API de qualité financière) et CIBA (authentification de canal de retour initiée par le client), mais en ce qui concerne FAPI, "des restrictions lors de l'utilisation d'OAuth / OIDC dans des endroits avec des exigences de sécurité plus élevées telles que le secteur financier" sont spécifiées. Vous pouvez le considérer comme un produit converti. Un exemple facile à comprendre est que l'authentification client OAuth Client lors de la prise de jetons n'est pas une authentification de base, alors préparez un certificat X.509, etc. ..
CIBA signifie OpenID Connect Client Initiated Backchannel Authentication Flow --Core 1.0. OAuth / OIDC (soi-disant RFC 6749) était ** une séquence de traitement sur site utilisant la redirection de navigateur WEB **, alors que [^ 1] , CIBA a une séquence de traitement consistant à ** envoyer une demande d'authentification au point de terminaison d'authentification du canal arrière ** et ** notifier le dispositif d'authentification de l'utilisateur pré-enregistré "Accepter?" **. Est une fonctionnalité. ..
[^ 1]: C'est impressionnant que la personne qui était sur scène ait expliqué cette séquence de traitement comme ** OAuth Dance ** :-)
Cela permet, par exemple,
--Lorsque vous dites à Alexa «Je vais acheter xxx, payer 3 000 ¥!», L'application Alexa envoie une demande d'authentification au serveur d'autorisation.
- Le serveur d'autorisation informe le dispositif d'authentification (application pour smartphone) de "Autoriser?"
- Si l'utilisateur appuie sur OK sur le smartphone, le paiement sera terminé.
Quelle séquence de traitement ne nécessitant pas de redirection du navigateur peut être réalisée. Eh bien, c'est vraiment pratique.
La séquence de traitement spécifique ressemble à ceci. ..
Intro
Eh bien, avant, j'ai eu l'occasion de toucher le service Authlete dans un certain projet de développement, et j'ai posté la procédure de construction à ce moment-là sur Qiita, bien qu'il s'agisse de Hello World.
Cette fois, j'ai eu la chance d'avoir l'opportunité de toucher le service Authlete compatible CIBA, donc je vais enregistrer la procédure de construction comme un rappel. (Je vous remercie!)
Connaissances préalables
C'est une condition préalable à la lecture de la procédure de construction ci-dessous, mais je continuerai en supposant que j'ai OAuth / OIDC et CIBA dans une certaine mesure. Par exemple, vous connaissez généralement la séquence de traitement du flux d'octroi de code d'autorisation ou du flux CIBA.
Ce qui suit est la séquence de traitement du flux d'octroi de code d'autorisation, appelée OAuth Dance. La position d'authentique est également écrite ensemble.
--Séquence de traitement du flux d'octroi de code d'autorisation
Cette fois, en touchant l'authentificateur compatible CIBA, j'essaierai de mettre en œuvre la séquence de traitement de flux CIBA suivante (précédemment publiée) ** et d'obtenir le jeton d'accès **. Pour les périphériques d'authentification, il existe un site de simulateur de périphérique d'authentification, utilisez donc ce site.
--Séquence de traitement du flux CIBA
En outre, il existe trois modes d'interrogation, de ping ou de push pour permettre au client OAuth de connaître le "résultat de l'utilisateur opérant sur le dispositif d'authentification (autorisation, refus, délai d'attente, etc.)" /openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.5), mais ** cette fois j'utiliserai "poll" **. Dans ce mode, le client OAuth interroge le serveur d'autorisation pour connaître le résultat de l'opération de l'utilisateur. Je n'ai pas encore essayé le ping et le push, mais dans le cas du ping, le serveur d'autorisation envoie une notification HTTPS disant "Viens le chercher, bon", et push semble envoyer le jeton d'accès tel quel. (Référence: 9. Client Notification Endpoint)
Environnement prérequis
L'environnement à cette époque est le suivant.
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.4
BuildVersion: 18E226
$ java -version
java version "1.8.0_91"
Java(TM) SE Runtime Environment (build 1.8.0_91-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.91-b14, mixed mode)
$ mvn --version
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-25T03:41:47+09:00)
$
$ curl --version
curl 7.54.0 (x86_64-apple-darwin18.0) libcurl/7.54.0 LibreSSL/2.6.5 zlib/1.2.11 nghttp2/1.24.1
$
$ jq --version
jq-1.6
$
Je le fais ci-dessus, mais si maven, curl, jq (et git) fonctionnent, je pense que tout y compris le système d'exploitation est OK.
Préparation
De plus, bien qu'il s'agisse d'un personnage tel que divers serveurs, dans article précédent
| Utilisation | Nom du serveur | URL |
|---|---|---|
| Serveur d'autorisation. Un serveur qui gère les informations d'autorisation pour chaque ID utilisateur. | java-oauth-server | http://oauth.example.com:8080/ |
| Serveur de ressources. Un serveur avec des données et des fonctions pour chaque ID utilisateur. | java-resource-server | http://resource.example.com:8081/ |
| Application Web. Applications Web qui utilisent des ressources du serveur de ressources | java-oauth-client | http://client.example.com:8082/ |
Cependant, cette fois, puisque l'article concerne l'obtention du jeton d'accès (ou id_token), le serveur de ressources est omis et la commande curl est utilisée comme client OAuth. Par conséquent, il a une structure simple comme indiqué ci-dessous.
| Utilisation | Nom du serveur | URL |
|---|---|---|
| Serveur d'autorisation. Un serveur qui gère les informations d'autorisation pour chaque ID utilisateur. | java-oauth-server | http://localhost:8080/ |
| Serveur de ressources. Un serveur avec des données et des fonctions pour chaque ID utilisateur. | réduction | - |
| Client OAuth. Une application qui utilise les ressources du serveur de ressources. | Cette fois, boucle | - |
Écoulement brutal
Le flux général est fondamentalement le même que l'utilisation conventionnelle d'Authlete.
- Inscrivez-vous pour Authlete
- Enregistrement du serveur d'autorisation / enregistrement du client
- Construction d'un serveur d'autorisation, construction d'un serveur de ressources (omis)
- Communication depuis l'application Web (jusqu'à ce que le jeton d'accès soit pris)
Cependant, comme décrit dans l'article Créer un serveur d'autorisation compatible CIBA à l'aide d'Authlete (Human in) , Il semble que vous deviez contacter Authlete pour vous inscrire à votre compte.
Par conséquent, dans cet article, le compte a été créé et les informations suivantes ont été obtenues sur le site Authlete compatible CIBA (généralement https://so.authlete.com/, mais la version compatible CIBA a une URL différente). Je vais partir du principe que.
- Clé API / secret API du serveur d'autorisation associé à ce compte
| Clé API | Secret de l'API |
|---|---|
| 116xxxxxxxx | sZUkxxxxxxxxxxxxxxxxxxx |
--OAuth Client ID client / secret client enregistré sur le serveur d'autorisation
| identité du client | Secret du client |
|---|---|
| 249xxxxxxx | WUItxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
En passant, vous pouvez vérifier la clé API / le secret API du serveur d'autorisation à partir de la liste de services suivante >> détails du service.
Vous pouvez également vérifier l'ID client / le secret client du client OAuth enregistré sur le serveur d'autorisation à partir de la liste des applications >> Détails de l'application sur la console de développement d'applications client.
Cadre environnemental
Maintenant, voici quelques préférences pour activer CIBA sur le site Web Authlete.
Paramètres côté serveur d'autorisation
Le site (console de l'administrateur du service) qui a confirmé la clé API / le secret API côté serveur d'autorisation plus tôt Allez dans l'onglet "Liste des services >> Détails du service >> CIBA" et allez à
| article | valeur |
|---|---|
| Modes de livraison de jetons pris en charge | POLL,PING,PUSH |
| Prise en charge du code utilisateur | soutenir |
Choisir.
Paramètres côté client OAuth
Transition vers "Liste des applications >> Détails de l'application" sur le site (console de développement de l'application cliente) où l'ID client / le secret client du client OAuth est confirmé.
Sur l'onglet "Informations de base"
| article | valeur |
|---|---|
| Type de client | CONFIDENTIAL |
Choisir.
Dans l'onglet "Autorisation"
| article | valeur |
|---|---|
| Méthode d'authentification du client | CLIENT_SECRET_BASIC |
Choisir.
Sur l'onglet "CIBA"
| article | valeur |
|---|---|
| Mode de livraison de jetons | POLL |
| Demande de code utilisateur | Demande |
Choisir.
Ceci termine les paramètres d'environnement pour le serveur d'autorisation et le client OAuth lorsqu'ils fonctionnent en mode POLL.
Essayez de bouger
Construire un serveur d'autorisation
Tout d'abord, créez un serveur d'autorisation. Clonez le référentiel GitHub et définissez la clé d'API, le secret d'API et l'url de base dans le fichier de configuration (authlete.properties).
$ git clone https://github.com/authlete/java-oauth-server.git
$ cd java-oauth-server
$ cat authlete.properties
service.api_key =116xxxxxxxx ← Veuillez changer pour la clé API correcte
service.api_secret =sZUkxxxxxxxxxxxxxxxxxxx ← Veuillez changer le bon secret API
base_url = https://api.authlete.com ← Veuillez passer à une URL compatible CIBA(Contactez Authlete pour la valeur)
Commencez.
$ mvn clean jetty:run -Dauthlete.ad.workspace=masatomix/testProject ← L'argument est une valeur à définir dans le simulateur qui viendra plus tard
Ceci termine la construction du serveur d'autorisation.
Préparation du dispositif d'authentification
Le serveur d'autorisation qui reçoit la demande d'authentification de backchannel envoie une notification au dispositif d'authentification "Puis-je l'autoriser?", Mais le code du serveur d'autorisation cloné est [Authlete CIBA Simulator](https: //) par défaut. Les notifications sont maintenant envoyées à cibasim.authlete.com/). Nous allons donc mettre en place le simulateur.
Allez sur https://cibasim.authlete.com/ et définissez l'argument ci-dessus,
| Namespace | Project |
|---|---|
| masatomix | testProject |
Spécifiez et cliquez sur "Créer". (La capture d'écran ci-dessous est "Ouvrir" après sa création.)
Ensuite, l'écran passera à l'écran du simulateur de périphérique d'authentification (AD). Le serveur d'autorisation fourni par Authlete est codé avec une authentification utilisateur factice.
| User ID | User Code |
|---|---|
| 1001 | 675325 |
Vous pouvez vous connecter à. Par conséquent, spécifiez l'ID utilisateur "1001" comme indiqué dans la capture et cliquez sur "Lancer le simulateur AD".
Le simulateur attend. Comme l'authentification / autorisation OAuth est effectuée sur cet écran, veuillez laisser l'écran ouvert (il semble qu'une notification push viendra ici avec WebSocket lorsque le serveur d'autorisation reçoit une demande d'authentification de canal arrière).
Au fait, si vous ouvrez cet écran avec un smartphone, vous ressentirez un sentiment de réalité. Lorsque vous envoyez une demande d'authentification de curl sur un PC qui n'a rien à voir avec cela, il semble qu'une notification arrive sur votre smartphone.
Renvoyer la demande d'authentification de canal
Maintenant, envoyons une demande d'authentification au serveur d'autorisation.
$ clientId=249xxxxxxx ← ID client
$ clientSecret=WUItxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ← Client secret
$ curl http://localhost:8080/api/backchannel/authentication -X POST \
--user ${clientId}:${clientSecret} \
-d 'login_hint=1001' \
-d 'user_code=675325' \
-d 'scope=openid'
{
"auth_req_id": "Xe250q9AoSdUL_xohrPm8txYNUo8VlddhLv1ENUY6SM",
"interval": 5,
"expires_in": 600
}
$
J'ai eu auth_req_id (ID de demande d'authentification). Notez-le car vous l'utiliserez plus tard.
Processus d'authentification sur le périphérique d'authentification
Lorsque vous envoyez la demande d'authentification, vous devriez voir l'écran d'autorisation avec lequel vous êtes familiarisé avec OAuth dans le simulateur. Sélectionnez "Autoriser" cette fois.
Envoyer une demande de jeton
Maintenant que l'utilisateur a été autorisé, l'auth_req_id mentionné précédemment est disponible. Maintenant que vous êtes prêt à obtenir le jeton, envoyez une demande de jeton.
$ clientId=249xxxxxxx ← ID client
$ clientSecret=WUItxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ← Client secret
$ curl http://localhost:8080/api/token -X POST \
--user ${clientId}:${clientSecret} \
-H 'Content-type: application/x-www-form-urlencoded' \
-d 'auth_req_id=Xe250q9AoSdUL_xohrPm8txYNUo8VlddhLv1ENUY6SM' \
-d 'grant_type=urn:openid:params:grant-type:ciba'
{
"access_token":"ldofpBo8hO67CNr4sE_Cibt1FYZ8RpQCIPVlUaeokks",
"refresh_token":"U0JyhKdXh-h3h6hDLiu3eart9RpEwnSClMtgGjAFu5o",
"scope":"openid",
"id_token":
"eyJhbGciOiJIUzI1NiJ9.eyJhdF9oYXNoIjoiRkxwdFBEaWlMbUcwdkVLWFZndjBUZyIsInN1YiI6IjEwMDEiLCJhdWQiOiIyNDkzOTMxNjU5OTciLCJhdXRoX3RpbWUiOjE1NTM4NTE3MjQsImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTUzOTM4MTM0LCJpYXQiOjE1NTM4NTE3MzR9.7G_VfqlSlDd0cOSjZaRorSrbcH3PoKneM_YalCpFHig","token_type":"Bearer","expires_in":86400
}
Vous avez un jeton d'accès! Puisque la portée est définie sur openid cette fois, id_token est également obtenu.
$ echo eyJhdF9oYXNoIjoiRkxwdFBEaWlMbUcwdkVLWFZndjBUZyIsInN1YiI6IjEwMDEiLCJhdWQiOiIyNDkzOTMxNjU5OTciLCJhdXRoX3RpbWUiOjE1NTM4NTE3MjQsImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTUzOTM4MTM0LCJpYXQiOjE1NTM4NTE3MzR9 | base64 -D | jq
{
"at_hash": "FLptPDiiLmG0vEKXVgv0Tg",
"sub": "1001",
"aud": "249393165997",
"auth_time": 1553851724,
"iss": "https://authlete.com",
"exp": 1553938134,
"iat": 1553851734
}
En fait, sondage
Étant donné que ce processus est effectué en interrogation entre les modes push, ping et poll, vous ne serez pas averti si la demande d'authentification est OK. Donc, en réalité, il semble que l'application ait besoin d'interroger après l'envoi de la demande d'authentification.
Par exemple, essayez d'exécuter le shell suivant.
$ cat ciba_request.sh
#!/bin/bash
clientId=249xxxxxxx ← ID client
clientSecret=WUItxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ← Client secret
login_hint=1001
user_code=675325
backchannelReq=`cat << EOS
curl http://localhost:8080/api/backchannel/authentication -X POST \
--user ${clientId}:${clientSecret} \
-d 'login_hint=${login_hint}' \
-d 'user_code=${user_code}' \
-d 'scope=openid' -s | jq .auth_req_id -r
EOS
`
auth_req_id=`eval "${backchannelReq}"`
echo ${auth_req_id}
for i in {0..3}; do
sleep 3
tokenReq=`cat << EOS
curl http://localhost:8080/api/token -X POST \
--user ${clientId}:${clientSecret} \
-H 'Content-type: application/x-www-form-urlencoded' \
-d 'auth_req_id=${auth_req_id}' \
-d 'grant_type=urn:openid:params:grant-type:ciba' -s
EOS
`
token=`eval "${tokenReq}"`
error=`echo ${token} | jq 'select(.error_description==null)'`
echo ${token} | jq
if [ -n "$error" ]; then
break;
fi
done
$ ./ciba_request.sh
lrHy0QdUalqpL7K2MRMfV_uhCLuvolCk5hS70LEb7R8
{
"error_description": "[A200308] The end-user has not been authenticated yet.",
"error": "authorization_pending",
"error_uri": "https://www.authlete.com/documents/apis/result_codes#A200308"
}
{
"error_description": "[A200308] The end-user has not been authenticated yet.",
"error": "authorization_pending",
"error_uri": "https://www.authlete.com/documents/apis/result_codes#A200308"
}
//Si vous appuyez sur Autoriser sur le simulateur ici. ..
{
"access_token": "RexqI1mrrCpVI9fiYJWhxuJMSSOfD6j1ijNXs-cXOts",
"refresh_token": "x0CuGD-CPK1q2b8WzuU5WYBeCoIxdkBg5aaenLCeeWQ",
"scope": "openid",
"id_token": "eyJhbGciOiJIUzI1NiJ9.eyJhdF9oYXNoIjoidVBRWVVnT1BmenVaQ1Jab0E1b21XUSIsInN1YiI6IjEwMDEiLCJhdWQiOiIyNDkzOTMxNjU5OTciLCJhdXRoX3RpbWUiOjE1NTQyNTc4NzksImlzcyI6Imh0dHBzOi8vYXV0aGxldGUuY29tIiwiZXhwIjoxNTU0MzQ0MjgxLCJpYXQiOjE1NTQyNTc4ODF9.1mdVZ2hub3GzwGNNxaL1HxlQHdIioSvLyp0UJfdMDog",
"token_type": "Bearer",
"expires_in": 86400
}
$
Ça m'a l'air bien. ..
Résumé
Cette fois, j'ai essayé de construire un serveur d'autorisation compatible CIBA (mode interrogation) en utilisant le service Authlete. Bien qu'il soit loin de comprendre le sentiment dans son ensemble simplement en construisant le toucher, j'ai pu facilement configurer le serveur d'autorisation en utilisant Authlete.
Merci pour votre soutien.
Liens connexes
- OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0 draft-02
- [Édition 2019] Technologie de certification et d'autorisation la plus avancée au monde, commentaire sur «CIBA» par les développeurs
- Créer un serveur d'autorisation compatible CIBA à l'aide d'Authlete
- FAPI (Financial-grade API) and CIBA (Client Initiated Backchannel Authentication)
- Le service d'autorisation Authlete prend en charge la nouvelle spécification "CIBA" qui élargit la scène d'application de l'API ouverte
- Authlete CIBA Simulator
- Création d'un serveur d'autorisation avec Authlete et communication depuis un client OAuth (application Web)
- Qu'est-ce que le flux d'authentification de canal arrière initié par le client OIDC (CIBA)? - Présentation