2022-04-26 14:03:46 +00:00
|
|
|
:PROPERTIES:
|
|
|
|
|
:ID: 97cfc6a5-3522-4ebc-99c6-704740ea97e8
|
|
|
|
|
:END:
|
|
|
|
|
#+TITLE: Token Exchange in IROH-Auth
|
|
|
|
|
#+Author: Yann Esposito
|
|
|
|
|
#+Date: [2022-04-26]
|
2022-04-26 14:06:11 +00:00
|
|
|
- tags :: [[id:91f33b35-6e4e-4213-b214-972ee20722df][Cisco]] [[id:299643a7-00e5-47fb-a987-3b9278e89da3][Auth]]
|
2022-04-26 14:03:46 +00:00
|
|
|
- source ::
|
2022-04-26 14:06:11 +00:00
|
|
|
|
|
|
|
|
- Token Exchange RFC :: https://www.rfc-editor.org/rfc/rfc8693.html
|
2022-04-26 14:07:23 +00:00
|
|
|
|
|
|
|
|
* Token Exchange
|
|
|
|
|
|
2022-04-26 14:08:59 +00:00
|
|
|
Token Exchange RFC describe an OAuth2 extension to support Token Exchanges.
|
|
|
|
|
With that RFC you could exchange an access token with another one.
|
|
|
|
|
|
|
|
|
|
It would immediately be useful to support the following features:
|
|
|
|
|
|
|
|
|
|
- provide impersonate ability to trusted clients
|
|
|
|
|
|
|
|
|
|
The RFC propose to use the existing ~/token~ endpoint.
|
2022-04-26 14:10:13 +00:00
|
|
|
|
2022-04-26 14:17:48 +00:00
|
|
|
Here would be an example for account switching:
|
2022-04-26 14:10:13 +00:00
|
|
|
|
2022-04-26 15:05:04 +00:00
|
|
|
#+begin_src http :pretty
|
2022-04-26 14:10:13 +00:00
|
|
|
POST /iroh/oauth2/token
|
|
|
|
|
Authorization: Basic XXXXXXXXXXXXX
|
|
|
|
|
Content-Type: application/x-www-form-urlencoded
|
|
|
|
|
|
|
|
|
|
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Atoken-exchange
|
2022-04-26 14:17:48 +00:00
|
|
|
&subject_token=JWT_WHERE_SUB_IS_USER_ID
|
2022-04-26 14:10:13 +00:00
|
|
|
&subject_token_type=
|
2022-04-26 14:14:42 +00:00
|
|
|
urn%3Aietf%3Aparams%3Aoauth%3Atoken-type%3Aaccess_token
|
2022-04-26 14:27:36 +00:00
|
|
|
&audience=iroh
|
|
|
|
|
&scope=profile
|
2022-04-26 14:10:13 +00:00
|
|
|
#+end_src
|
2022-04-26 14:14:42 +00:00
|
|
|
|
|
|
|
|
The call takes:
|
|
|
|
|
|
2022-04-26 14:26:14 +00:00
|
|
|
- Authorization contain the info about the Client (id + secret)
|
|
|
|
|
- Some JWT signed by the client containing some SecureX ~user-id~
|
|
|
|
|
- optionally a list of scopes
|
|
|
|
|
- optionally some audience
|
2022-04-26 14:27:36 +00:00
|
|
|
|
2022-04-26 14:28:37 +00:00
|
|
|
And should return an access token of this user.
|
|
|
|
|
So we could provide a client that would just need to know some user-id to
|
|
|
|
|
be able to get a JWT of this user.
|
2022-06-01 08:37:10 +00:00
|
|
|
* Token Exchange support Okta tokens
|
|
|
|
|
|
|
|
|
|
The end goal is to provide a mechanism for a team that support Okta login to
|
2022-06-01 08:38:41 +00:00
|
|
|
retrieve tokens from SecureX for the User's accounts.
|
2022-06-01 08:40:25 +00:00
|
|
|
|
2022-06-01 08:42:34 +00:00
|
|
|
*** This Document Terminology
|
2022-06-01 08:40:25 +00:00
|
|
|
|
2022-06-01 08:43:48 +00:00
|
|
|
- /SecureX user/ or simply /user/ => a SecureX user belongs to a known org
|
2022-06-01 08:44:51 +00:00
|
|
|
- /SecureX org/ or simply /org/ => The org in SecureX, can be assimilated to the tenant
|
2022-06-01 08:43:48 +00:00
|
|
|
- /SecureX account/ or simply /account/ => a couple SecureX user with its associated SecureX org
|
|
|
|
|
- /User Identity/ or /IdP User/ or /Okta User/ => a user identified via an IdP. Such a user can reach
|
2022-06-01 08:40:25 +00:00
|
|
|
potentially multiple SecureX accounts.
|
2022-06-01 08:43:48 +00:00
|
|
|
- /tenant/ => can be assimilated to SecureX org in this document
|
2022-06-01 08:46:37 +00:00
|
|
|
- /client/ => the client configured in SecureX, it could be owned by a
|
|
|
|
|
user, org or be global
|
2022-06-01 08:48:09 +00:00
|
|
|
- /
|
2022-06-01 08:41:33 +00:00
|
|
|
|
2022-06-01 08:42:34 +00:00
|
|
|
*** Token Exchange RFC
|
|
|
|
|
|
|
|
|
|
To reduce to the essential the Token Exchange RFC using our own terminology:
|
