[OAUTH-WG] Grant flow for delegated auth
Sergey Ponomarev <stokito@gmail.com> Thu, 24 May 2018 07:18 UTC
Return-Path: <stokito@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9651242F7 for <oauth@ietfa.amsl.com>; Thu, 24 May 2018 00:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hukshWTR440 for <oauth@ietfa.amsl.com>; Thu, 24 May 2018 00:17:59 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F18124B0A for <oauth@ietf.org>; Thu, 24 May 2018 00:17:58 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id e80-v6so543431oig.11 for <oauth@ietf.org>; Thu, 24 May 2018 00:17:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5IZ9n1t+G01RZw6QCBwaZcn4AhfxOFeCHUfSINuaCj0=; b=LqAk1i4oWHpNW6Bzx8rNtO3dsnz+meLQmFafPufX8QwSDiGBDq1B57ccJUyjAMvrR/ shmVp+ypc3JtzYYSuEI33ZaRX+2BSZNQpPMJVyT+Lcq/8/XM87w8I/vGWMX5RNpo2KqB 82Zqt8z/yyduIHeDSlMaXXMSgO6w5qMql/bAHQusL28L+QpR3vd5D3C7m1XGoI1BYEHL gdLcRfxxH5dfCL80lXImaI8OvvhXV2ATYwVsYKwhQb0Yfr30vene3Kj/vmmA4jbZhTmM srK4cdYOKvR+k8WrdtNwsf3zcm8mVpoDMGRSRJ7hwAp8MHZMguNsFx8i1NBKGBstOTU/ cfrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5IZ9n1t+G01RZw6QCBwaZcn4AhfxOFeCHUfSINuaCj0=; b=Yv6EoL2dH2r9TSEUKpVsdx0FB/toG1YGLnQs9/y+ZeoDCpvoN3Te405SnaKDd6G6XH YLnDVIcBbdIU2QkP36wacJsSo9I5ENoxWBa/6u9lpfq3ah2EtFxx4kzdqHvgRM4rTJG6 dCKvn1caYOjUcrFPmRBJV3pgl6AiAzuesM1L1Fejg1fOdTgoKcwz0cZzrTq+Im96kLhc rkn0A64y1DDUklEduiygqdD6tMd9tXugl6WczGOir3OcA66ujWazGQhfNGZxfulmUd3p rlHqbgIu5rXSpsR85eteOl61HnMsjxtrLkJJtkHHoh1CziM7rBHbEXcMsRTmu3KgvHXV GvNw==
X-Gm-Message-State: ALKqPwd2nHKnQqsX9zX8DKYWDwV6OJTK+6D5eqJkfb5TPHNSKuw/uqaG WeMZjvwrX5+fSQpCTYXEenq/jz7xqWFBIN+xVRGwLhlM
X-Google-Smtp-Source: AB8JxZopXcyFkDawVQKooPoDVUxGI4gdnI4RJM99V9DkGQI/DAWvWfrfN9IFn60SBLRqhBlu4OgrEKS9ucgCPNuheiA=
X-Received: by 2002:aca:e889:: with SMTP id f131-v6mr3432360oih.324.1527146277094; Thu, 24 May 2018 00:17:57 -0700 (PDT)
MIME-Version: 1.0
From: Sergey Ponomarev <stokito@gmail.com>
Date: Thu, 24 May 2018 10:17:20 +0300
Message-ID: <CADR0UcVJk+rCdmOHKbmvQN_Paa8OjX-nnTKFoZ0g2GGfBOZQVQ@mail.gmail.com>
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005dcaad056cee73fd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/w5igVuPo5jVk9qPmgEDwzGU8aao>
Subject: [OAUTH-WG] Grant flow for delegated auth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 May 2018 07:18:03 -0000
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>
- [OAUTH-WG] Grant flow for delegated auth Sergey Ponomarev
- Re: [OAUTH-WG] Grant flow for delegated auth Brian Campbell