Isn’t this essentially what is mitigated in the FAPI-compliant OIDC CIBA by:
1. Requiring the client to initiate the flow with signed request parameters
which include, via some hint, the resource owner for whom authentication is
being requested
2. Requiring that the OP check that the resource own
.
Cheers,
Shane.
From: Sergey Beryozkin
To: Shane B Weeden/Australia/IBM@IBMAU
Cc: oauth@ietf.org
Date: 03/04/2013 06:23 PM
Subject:Re: [OAUTH-WG] OAuth mobile flow
Hi Shane, All,
The info below (and the links shared by others) is useful, thanks,
I have a single question
client id, but again it's still a possibility.
Regards,
Shane.
From: Sergey Beryozkin
To: oauth@ietf.org
Date: 25/03/2013 06:01 PM
Subject:Re: [OAUTH-WG] OAuth mobile flow
Sent by:oauth-boun...@ietf.org
Hi Shane
On 25/03/13 00:54, Shane B Weeden wrote:
> The
There are several options. I've developed a few based on azn code flow with
custom "delivery" of the code, and also resource owner password credentials
flow with a public client id (although I personally don't like the idea of
ever presenting my real credentials to the phone but business owners see
Sounds like a sensible approach Bob - and thanks for the discussion as it's
real-world issues like this which ultimately really matter.
From: Bob Gregory
To: Shane B Weeden/Australia/IBM@IBMAU
Cc: Tim Bray , Brian Eaton ,
OAuth WG , oauth-boun...@ietf.org
Date:
My understanding is that it is considered a best practice to rollover a
refresh token on each use - that is when a refresh token is used, both a
new access token and a new refresh token are issued, and the old refresh
token is revoked.
The primary reason I have seen cited for this is it would allo
You're on the right track.
If you're interested, I have a demo of exactly what you are talking about
using the authorization code flow (and in this case manual entry of the
short-lived azn code). It uses refresh tokens precisely just as you
suggest:
https://www-304.ibm.com/connections/blogs/sweede
IMO the scenario as documented doesn't make complete sense in the context
of OAuth 2.0 as it says that Bob uses the access token to access Alice's
photos. Clients in OAuth 2.0 are not people, they are programs.
From: David Fox
To: "'OAuth WG'"
Date: 12/03/2012 12:15 PM
Subject:
1. Yes, client credentials sounds right for what you described. Think of it
as lightweight b2b authentication in that sense (but two steps - one to get
a token, and another to use it).
2. Can't help you with source - but do have a product-based solution :)
3. Absolutely it should for the resource s
I agree with others - this is not an attack on the protocol. The user has
the choice about which scope to grant and the client's redirect to the
authorization endpoint is only a request for a particular set of
permissions, not a guarantee that it will get them. The user+authorization
server decide
You can also use the authorization code flow with a form of custom (e.g.
manual) delivery of the authorization code from the authorization server to
your client rather than via a redirect.
Some important points about that:
The resource owner must still visit the real authorization endpoint with a
I don't think one can presume that client identifiers are any kind of
secret particularly given that for web-based flows they are transmitted in
browser redirects.
The "meaningful"-ness of the information is debatable as on the other hand
security best practices generally support the idea that the
Mike - I don't think that's true for the resource owner password
credentials flow that you showed below.
The Authorization header is authenticating the client, the
username/password POST body params represent the resource owner.
From: Mike Jones
To: "oauth@ietf.org"
Date: 26-07-11 02
Looking at the .txt version:
1. Line 260 s/authentication/authenticate
OAuth defines two client types, based on their ability to maintain
the confidentiality of their client credential, used to
authentication with the authorization server:
2. Line 274 s/with with/with
Before initiat
From 4.2.1 below:
The authorization server validates the request to ensure all
required parameters are
present and valid. The authorization server MUST verify that
the redirect URI to which
it will redirect the access token matches a redirect URI
pre-registered
Sounds reasonable - subject to the content of the validation rules for a
registered redirect URI (section 10.11 TBD). The security considerations
doc (or section 10.13 of the spec itself which is TBD) should make it clear
that the state parameter must be provided by the client to prevent CSRF
again
One might argue these are deployment-time considerations rather than spec
issues.
From: Thomas Hardjono
To: Shane B Weeden/Australia/IBM@IBMAU
Cc: "oauth@ietf.org"
Date: 21-06-11 04:03 AM
Subject:RE: [OAUTH-WG] Client authentication requirement
> Fro
As I understand it, what you've described is precisely the intent of the
refresh token. The online registration process you refer to is a
corresponding one-time authorization code flow. The authorization code
effectively becomes a one-time-use, short-lived credential for the client
instance which i
Brian Eaton wrote on 16-06-2011 10:36:18 AM:
> From: Brian Eaton
> To: Shane B Weeden/Australia/IBM@IBMAU
> Cc: OAuth WG
> Date: 16-06-11 10:49 AM
> Subject: Re: [OAUTH-WG] Client authentication requirement
>
> On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden
wro
> From: Eran Hammer-Lahav
> To: OAuth WG
> Date: 16-06-11 05:43 AM
> Subject: [OAUTH-WG] Redirection URI and Implicit grant
> Sent by: oauth-boun...@ietf.org
>
> This is coming from recent experience building a full web service
> and multiple clients using OAuth 2.0. I am going to make these
> ch
Eran: > > I would like to go back to requiring client authentication for
the access token endpoint
Brian: > Sure. Why not?
>
> 1) It makes the spec simpler.
> 2) It has no impact on the security of clients that can't keep secrets.
> 3) It has no impact on the security of clients that can keep sec
Just an observation - some of this function seems to have direct parallels
in OpenID.
E.g.
display=none sounds very much like checkid_immediate
prompt=xxx seems like a direct correlation to the PAPE extension
Could things like signed_request and nonce be considered part of a custom
token format i
Would anyone care to explain what the value of a refresh token is for peer
to peer applications utilizing the client_credentials grant type, or
validate if my explanation is the intended use case?
Recall:
* it is required to provide client credentials to get an access token [and
refresh token]
*
First, I'd like to add my support for Brian Eaton's comments on Draft 16.
They actually helped clarify the comment I have below
I found section 9 to be in contradiction to a part of section 6. In
particular in section 9:
Native applications SHOULD use the authorization code grant type flow
24 matches
Mail list logo
