[OAUTH-WG] Grant flow for delegated auth

2018-05-24 Thread Sergey Ponomarev 
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 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

2018-05-24 Thread Brian Campbell 
Take a look at RFC 7523 's JWT
Authorization Grant.

On Thu, May 24, 2018 at 1:17 AM, Sergey Ponomarev  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 
>
> ___
> 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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Comments on draft-ietf-oauth-security-topics-06.txt

2018-05-24 Thread Joseph Heenan 
Hi Denis,

This presentation is only describing one attack. Page 12 summarises it. The 
attack is not a full attack targeted against oauth, but it shows how a 
malicious network can steal any codes returned to the browser in the URL, even 
if the codes are always sent over TLS.

I was only responding to your assertion that PKCE is not required when TLS is 
in use. I believe that assertion was not right, as the above attack is against 
TLS enabled servers and PKCE would have made any stolen auth code useless, so 
PKCE still has value even when using TLS.

Thanks

Joseph


> On 23 May 2018, at 12:58, Denis  wrote:
> 
> Hi Joseph,
> 
> Among these 39 slides, to which attack(s) are you referring ?
> 
> I wrote:"It is quite hard to understand under which context(s) and conditions 
> OAuth 2.0 could be safely used".
> 
> For each counter-measure, it would be useful to explain under which 
> context(s) or under which assumptions 
> it should be used. 
> 
> Denis
> 
>> Hi Denis,
>> 
>>> On 22 May 2018, at 14:05, Denis >> > wrote:
>>> In particular, the text states:
>>> 
>>>"Clients shall use PKCE [RFC7636] in order to (with the help of the 
>>> authorization server) detect and prevent attempts 
>>> to inject (replay) authorization codes into the authorization 
>>> response".
>>> 
>>> This is incorrect, since RFC7636 should be used when the authorization code 
>>> is returned from the authorization endpoint
>>> within a communication path that is not protected by Transport Layer 
>>> Security (TLS).
>>> 
>> That is not really the full story as we've seen attacks where URLs that you 
>> would expect to be protected by TLS are vulnerable; one example is:
>> 
>> https://www.blackhat.com/docs/us-16/materials/us-16-Kotler-Crippling-HTTPS-With-Unholy-PAC.pdf
>>  
>> 
>> 
>> IMHO it would be sane to use PKCE anywhere where a code is returned in the 
>> URL and there isn't another proof of possession / token binding mechanism in 
>> play.
>> 
>> Joseph
>> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] I-D Action: draft-ietf-oauth-reciprocal-00.txt

2018-05-24 Thread internet-drafts 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.

Title   : Reciprocal OAuth
Author  : Dick Hardt
Filename: draft-ietf-oauth-reciprocal-00.txt
Pages   : 4
Date: 2018-05-24

Abstract:
   There are times when a user has a pair of protected resources that
   would like to request access to each other.  While OAuth flows
   typically enable the user to grant a client access to a protected
   resource, granting the inverse access requires an additional flow.
   Reciprocal OAuth enables a more seamless experience for the user to
   grant access to a pair of protected resources.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-oauth-reciprocal-00
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-reciprocal-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAUTB for Access Token in Implicit Grant

2018-05-24 Thread Brian Campbell 
Yeah, that's what is implied. At least given the way that
https://tools.ietf.org/html/draft-ietf-tokbind-https provides to signal to
the client to reveal the Referred Token Binding.

I've heard that there's some potential for the Fetch spec to provide some
APIs or controls around Token Binding, which might facilitate other ways of
getting the Referred Token Binding into a request. But I don't know the
details or likelihood or timeline. And whatever form that takes may or may
not facilitate other options for 'front-channel' requests to the
authorization endpoint.


On Wed, May 23, 2018 at 10:27 AM, Daniel Fett  wrote:

>
> Just to clarify: This implies that there must be an HTTP(S) request from
> the browser to the protected resource which then gets redirected to the
> authorization endpoint. Is that correct?
>

-- 
_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._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth