[Openid-specs-ab] Recruit's SIOP implementation

Kristina Yasuda Kristina.Yasuda at microsoft.com
Wed Sep 2 02:19:45 UTC 2020


Hi,

I had a conversation with Recruit who is currently using SIOP flow to authenticate users across 10+ apps owned by Recruit<https://www.recruit.co.jp/en/>, a large Japanese HR tech company. It is a closed ecosystem with 90 million total users<https://paymentnavi.com/paymentnews/96205.html?fbclid=IwAR3Dq2mLZHM5UbvrimkHbIjFscIhMKlclMPJlpH5i3bmRu8UfxKvgOvSXW4> (number of active users are not public, but should be much less).

Please find detailed notes below

  *   Value / why chose SIOP
     *   for app A and B offered by Recruit, users using app A do not have to enter ID/Pass when logging in to app B on the same device (to reduce churn rate)
  *   Flow (Image from the deck<https://speakerdeck.com/rtechkouhou/openid-connect-self-issued-idpwoying-yong-sitasingle-sign-onfalseshi-zhuang?slide=29> attached )
     *   User registers public key (thimbprint) with Recruit's authorization server (need to sign-in using Recruit ID on the device).
     *   Authorization server sends a nonce to SIOP (new nonce every time)
     *   SIOP sends back signed id-token and nonce
     *   User signs-in to the app (this step will be omitted after the second log-in if AS can validate id_token using public key's thumbprint and nonce)
  *   Highlights
     *   there is a variation of the above flow that uses biometrics (uses acr and amr claims)
     *   not using Claims parameter
     *   key rotation
        *   for internal use-cases (apps managed by the same company, Recruit), they would like to continue using JWK's thumbprint in sub field. If thumbprint value changes everytime, they cannot step 4 in the above flow cannot be omitted + they would not be able to tie several apps to one user
        *   for inter-company use-cases, they see the benefit of introducing key rotation
        *   Key rotation would be beneficial for recovery when device is lost
        *   adding URN in sub field should not require a lot of changes in current implementation..

Some of the issues in SIOP Laundry List were not relevant to Recruit's implementation which is closed to Recruit ecosystem. (Claims binding, SIOP discovery, etc.)
Regarding adding the level of indirection to 'sub' field, they were welcoming the change, but wanted to see current 'sub' = thumbprint of the key implementation remaining valid.

Best,
Kristina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200902/3107a823/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Recruit_SIOP.JPG
Type: image/jpeg
Size: 159503 bytes
Desc: Recruit_SIOP.JPG
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20200902/3107a823/attachment-0001.jpe>


More information about the Openid-specs-ab mailing list