Subject: [OAUTH-WG] Grant flow for delegated auth

From: Sergey Ponomarev <[email-masked]>
Date: Thu, 24 May 2018 10:17:20 +0300

Hi,

My Auth Server (AS)  implementation has a client (server of another
platform) which makes authorization on it's side but it needs to populate
user info to my AS and receive an access token to work with my my platform.
What I mean that they need just login user to my platform but without
user's credentials.
So user's credentials are on client side but session management (login,
logout) on my platform's side. As I understood, this is something similar
to federation.

We can't use a Password Grant Flow in this case because the client will not
send a user's password. Also my AS needs some basic use info and instead of
pulling a user info from AS the client push it.
I going to introduce and implement a new grant flow, let's call it
"delegated" and it looks similar to Password grant flow but without user's
password and it receives id_token with user's info.
POST request to Token Endpoint with form params: grant_type=delegated,
client_id,client_secret,username,scope and id_token:

curl -X POST \
  https://authserver/oauth/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -d
'grant_type=delegated&client_id=acme&client_secret=acmesecret&username=user&scope=openid&id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz%0AcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4%0AMjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi%0Abi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz%0AMTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6%0AICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm%0AZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6%0AICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l%0AeGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn%0AspA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip%0AR2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac%0AAAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5RZOQ0TLrOY%0Au0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD%0A4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-rDaQzUHl%0A6cQQWNiDpWOl_lxXjQEvQ'

And response contains access_token.

So my question is: maybe something similar already exists in specification?
If no, then what usually used in this case?

Regards,
Sergey Ponomarev <https://linkedin.com/in/stokito>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 24 May 2018 10:54:26 -0600

Take a look at RFC 7523 <https://tools.ietf.org/html/rfc7523>'s JWT
Authorization Grant.

On Thu, May 24, 2018 at 1:17 AM, Sergey Ponomarev <[email-masked]> wrote:

> We can't use a Password Grant Flow in this case because the client will
> not send a user's password. Also my AS needs some basic use info and
> instead of pulling a user info from AS the client push it.
> POST request to Token Endpoint with form params: grant_type=delegated,c
> lient_id,client_secret,username,scope and id_token:
>
> curl -X POST \
>   -d 'grant_type=delegated&client_id=acme&client_secret=
> acmesecret&username=user&scope=openid&id_token=
> eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ.ewogImlz%
> 0AcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4%
> 0AMjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAi%
> 0Abi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEz%
> 0AMTEyODA5NzAsCiAibmFtZSI6ICJKYW5lIERvZSIsCiAiZ2l2ZW5fbmFtZSI6%
> 0AICJKYW5lIiwKICJmYW1pbHlfbmFtZSI6ICJEb2UiLAogImdlbmRlciI6ICJm%
> 0AZW1hbGUiLAogImJpcnRoZGF0ZSI6ICIwMDAwLTEwLTMxIiwKICJlbWFpbCI6%
> 0AICJqYW5lZG9lQGV4YW1wbGUuY29tIiwKICJwaWN0dXJlIjogImh0dHA6Ly9l%
> 0AeGFtcGxlLmNvbS9qYW5lZG9lL21lLmpwZyIKfQ.rHQjEmBqn9Jre0OLykYNn%
> 0AspA10Qql2rvx4FsD00jwlB0Sym4NzpgvPKsDjn_wMkHxcp6CilPcoKrWHcip%
> 0AR2iAjzLvDNAReF97zoJqq880ZD1bwY82JDauCXELVR9O6_B0w3K-E7yM2mac%
> 0AAAgNCUwtik6SjoSUZRcf-O5lygIyLENx882p6MtmwaL1hd6qn5R
> ZOQ0TLrOY%0Au0532g9Exxcm-ChymrB4xLykpDj3lUivJt63eEGGN6DH5K6o33TcxkIjNrCD%
> 0A4XB1CKKumZvCedgHHF3IAK4dVEDSUoGlH9z4pP_eWYNXvqQOjGs-
> rDaQzUHl%0A6cQQWNiDpWOl_lxXjQEvQ'
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._