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

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 <stokito@gmail.com> wrote:

> 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,c
> lient_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-O5lygIyLENx882p6MtmwaL1hd6qn5R
> ZOQ0TLrOY%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>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> 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._