Re: [OAUTH-WG] Device Authorization Grant and Illicit Consent Exploits
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 owner approving the grant is the same as that the client associated with the request in step 1 I realise this requires that the client obtains an indication of the username of the resource owner up front to kick things off, but short of this I cannot think of any practical mitigation. On 18 Mar 2022, at 7:09 am, Pieter Kasselman mailto:pieter.kasselman=40microsoft@dmarc.ietf.org>> wrote: ant problem by enabling authorization flows on devices that are unable to support a browsers or have limited input capabilities. However, looking back over the past 18-24 months, there have been a number of practical exploits published that use social en ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Client Credentials and Refresh Tokens
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] * it is also required to provide client credentials to exchange a refresh token for an access token (small assumption here based on recent discussions ... but I think it had better be for the client_credentials flow) * unlike the authorization code flow, there is no authorization step with the user involved that makes obtaining a new access token directly from the client credentials any less onerous than using a refresh token About the only use case I can contrive that makes any sense is when multiple instances of apps use the same client credentials (already a bad idea) and you want to revoke access to a subset of them. To do the revocation you would need to simultaneously: 1. Revoke the refresh token and any access tokens issued to compromised instances 2. Update the client secret (or whatever authentication method clients have) on those client instances that are still considered ok. In a deployment where each client has it's own credentials, which should be "situation normal" from a security perspective, I don't see any value for the refresh token. I also cringe at the idea of someone suggesting that refresh token can be presented without client credentials - in this case that's like saying client X has n passwords, where n is the number of issued refresh tokens. Better to create n sets of client credentials in the first place. Thanks, Shane. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Proposed OAuth Extensions
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 in a separate token spec rather than part of the core -
provided the client can be token-type-aware?
From: Paul Tarjan
To: "oauth@ietf.org"
Date: 07-06-11 11:57 AM
Subject:[OAUTH-WG] Proposed OAuth Extensions
Sent by:oauth-boun...@ietf.org
Hi fellow OAuthers,
As we discussed at the meeting there are a few extensions that we'd like
to implement. To do this, we'd like the response_type to be extensible. We
are proposing two new values. "none" and "signed_request token" (and
"token signed_request" for symmetry). Or if you want to turn response_type
into a space separated list, that would work too.
I'm also including our other extension parameters so you can see what we
are planning incase others need similar functionality.
---
response_type=none
If this is specified then no code nor token is passed to the redirect_uri.
This is very useful when the authentication will be done via other means
(like the display=none parameter, or Facebook's canvas iframe).
Example:
http://www.facebook.com/dialog/OAuth?
client_id=150629244948164&
redirect_uri=http://apps.facebook.com/ptarjan/&;
response_type=none
(shows user the permission dialog then redirects to)
http://apps.facebook.com/ptarjan/
(or if they click cancel)
http://apps.facebook.com/ptarjan/?
error=access_denied&
error_description=...&
state=...
---
response_type=signed_request
This response type is used to tie the Javascript SDK to a server-side SDK.
It is used in conjunction with response_type=token and display=none. It
sends a "signed_request" along with the response, which is a signed blob
that we expect the JS library to dump into a cookie for the server SDK to
read and validate. The JS SDK will also look inside of it (without
verifying the signature) to see the user's ID. That is safe because the JS
SDK uses state and only handles responses it's expecting.
The signed_request will contain:
user_id (provider specific id string)
issued_at (UNIXTIME)
code (optional. OAuth code issued with redirect_uri set to ""
since the server won't know which URL it was issued on)
client_id (optional. Needed by Google for 4th party auth)
audience (optional. Google's public key crypto)
... (other provider specific data)
Example:
http://www.facebook.com/dialog/OAuth?
client_id=150629244948164&
redirect_uri=https://s-static.ak.fbcdn.net/connect/xd_proxy.php#&;
display=none&
response_type=token signed_request
302s to
https://s-static.ak.fbcdn.net/connect/xd_proxy.php#
access_token=...&
expires_in=...&
signed_request=abcd...
And the JS SDK then does
setcookie("fbc_"+client_id, signed_request)
---
display=none
This means the user never will see a dialog and is meant to be opened in
an iframe by javascript to asynchronously get an access_token or discover
the user's state.
Example:
http://www.facebook.com/dialog/OAuth?
client_id=150629244948164&
redirect_uri=https://example.com/&;
display=none&
response_type=token
If the user is not logged into Facebook, this endpoint 302s to
https://example.com/#
error=unknown_user
If the user is logged in but hasn't authorized this app, it 302s to
https://example.com/#
error=not_authorized
If the user has authorized the app then it 302s to the normal OAuth output
https://example.com/#
access_token=...&
expires_in=...
---
prompt=
A parameter that changes some things with the OAuth prompt. These can be
specified as a space/comma separated string.
prompt=login
This forces the user to enter their password again.
prompt=consent
This always shows the "Do you allow this app" dialog, even if they
consented before. Google will only issue long lived tokens when the user
clicks something.
prompt=secure
The user must be verified by secure (https) cookies. This protects the app
from firesheep attacks.
prompt=select_account
The user will be shown a dialog to select amongst their connected accounts
(Google wants this for multiple connected accounts).
---
nonce=
If this parameter is specified, the nonce is encoded in the access_token,
which is then accessible via a "Token Info Endpoint". This is paired with
prompt=login to guarantee the user put in their password before they buy
something expensive with their paypal account.
It is limited to a 20 character opaque string, but we recommend base64url
encoding a set of random bits.
Example:
http://www.facebook.com/dialog/OAuth?
client_id=150629244948164&
redirect_uri=...
nonce=some_string
response_type=code
Does exactly the same OAuth flow, except when they hit
https//graph.facebook.com/access_token?access_token=...
They get back json with a key "nonce" bei
Re: [OAUTH-WG] Client authentication requirement
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 secrets. Brain - can you elaborate on that a little? Are you suggesting that clients that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy "requiring client authentication"? I can't see any point in the spec saying client authentication is required if it doesn't add value in a way that can be explained to everyone (eg. what you said in http://www.ietf.org/mail-archive/web/oauth/current/msg06362.html about rolling over the client secret to deal with compromised refresh tokens). What seems to be missing in the discussion and the security considerations of the spec is a decent list of general and grant-type-specific security implications/pros/cons for the system if meaningful client authentication at the token endpoint is available or not available. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Redirection URI and Implicit grant
> 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 > changes to my own implementation and would like to raise the > questions here and discuss possible changes. > > A few questions: > > 1. Why not require the registration of a redirection URI for > implicit grant requests, removing the redirect_uri parameter > completely from the request (the client can still use the state parameter)? I can imagine situations where one-or-more redirect URI's may be required rather than a single explicit URI. I think that either a child-urlpath-of-the-registered URI, and/or the ability to register multiple valid URI's for a particular client id allows this without being overly restrictive. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication requirement
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 wrote: > Brain - can you elaborate on that a little? Are you suggesting that clients > that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy > "requiring client authentication"? > > Or use random secrets. Whatever floats your boat and keeps your > product managers happy. It does not make a practical security > difference for installed applications. That is the same thing as not requiring client authentication at all (for installed applications). Having the spec say client authentication is REQUIRED for the token endpoint is therefore misleading and nonsensical. > > What seems to be missing in the discussion and the security considerations > of the spec is a decent list of general and grant-type-specific security > implications/pros/cons for the system if meaningful client authentication > at the token endpoint is available or not available. > > Yep. I believe this piece of work would go a long way to settling the disputes about when/why/if client authentication should be required at the token endpoint. For example I would like to see attempts to answer this question: If client authentication is not possible or required at the token endpoint for native/installed apps, what advantages are gained from requiring it for clients that can authenticate? ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Client authentication requirement
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 it should use immediately (since it has been exposed to the resource owner via the user-agent in getting to the client) to directly request an access token (typically short-lived and may not be needed immediately) and refresh token (typically long-lived). The refresh token is stored securely locally. It is essentially an instance secret bound to the client id and representing the original resource owner grant. Provided: 1. The resource owner and user-agent safely deliver the authorization code to the client instance in first place 2. The client uses it immediately in secure transport-level communications to the authorization server and then securely stores the long-lived refresh token 3. The client always uses the refresh token in secure transport-level communications to the authorization server to get an access token (and optionally rollover the refresh token) .. then securely authenticating the client doesn't seem to be a big deal. I trust "the list" will correct me if that's a wrong interpretation of a classic native app scenario. It still leads to my question from some posts ago about why then is it advantageous to require client authentication at all for the authorization code flow in classic web app three-legged scenarios, and I am yet to fully digest Torsten's response to that ( http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01). About the only documented advantage I've seen to date has to do with the recovery/next steps from a compromised refresh token, but the usefulness of that idea has been debated as well. From: Dave Nelson To: Brian Eaton Cc: "oauth@ietf.org" Date: 17-06-11 09:45 PM Subject:Re: [OAUTH-WG] Client authentication requirement Sent by:oauth-boun...@ietf.org > If you aren't willing to accept the risk of native apps that can't keep > secrets, don't support such apps. We continue to say "can't keep secrets". I think what we mean is "can't keep secrets that are embedded in the code". One could imagine an install-time, leap-of-faith binding to a remotely received secret, via some on-line registration process, that the native app asks the operating system to store for it securely. The user can make an assertion of trust in the validity of the app that he/she has downloaded and is subsequently installing. Of course, that initial faith might be misplaced, but that's true of almost all user-installable software, even that receive on physical media. If browsers are trusted to store secrets securely, then that same capability is available to native apps. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 ___ 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
Re: [OAUTH-WG] Client authentication requirement
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 > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Friday, June 17, 2011 11:31 AM > To: Shane B Weeden; Dave Nelson > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Client authentication requirement > > Shane B Weeden schrieb: > > >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 it should use immediately (since it has been > >exposed to the resource owner via the user-agent in getting to the > >client) to directly request an access token (typically short-lived and > >may not be needed > >immediately) and refresh token (typically long-lived). The refresh > >token is stored securely locally. It is essentially an instance secret > >bound to the client id and representing the original resource owner > >grant. Provided: > >1. The resource owner and user-agent safely deliver the authorization > >code to the client instance in first place 2. The client uses it > >immediately in secure transport-level communications to the > >authorization server and then securely stores the long-lived refresh > >token 3. The client always uses the refresh token in secure > >transport-level communications to the authorization server to get an > >access token (and optionally rollover the refresh token) .. then > >securely authenticating the client doesn't seem to be a big deal. > > > >I trust "the list" will correct me if that's a wrong interpretation of > >a classic native app scenario. > > I fully agree with your description. > Shane: The issue is actually best summarized by your own email. Client authentication is not needed provided (1), (2) and (3). This is a lot of assumptions to rely on. > > 1. The resource owner and user-agent safely deliver the > > authorization code to the client instance in first place What does "safely deliver" mean? How is it implemented and deployed? > > 2. The client uses it > > immediately in secure transport-level communications > > to the authorization server and then securely stores > > the long-lived refresh token. What is the time-limit for "immediately"? (60 secs, 30 mins, 24hr?). > > 3. The client always uses the refresh token in secure > > transport-level communications to the authorization > > server to get an access token Oauth2.0-draft16 only devotes two lines to X509 certificates (Section 10.6), for the authorization-server and client interaction. Its not clear how binding is done (eg. binding of the TLS session and transaction), for example for audit/logging purposes. /thomas/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] state parameter and XSRF detection
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 against the redirect_uri unless the client is already using another dynamically parameter in the redirect_uri for that purpose. Text should also include some recommendation on state parameter entropy, along with describing how it should be validated when the redirect_uri is accessed. Regards, Shane. From: Torsten Lodderstedt To: OAuth WG Date: 28-06-11 07:26 AM Subject:[OAUTH-WG] state parameter and XSRF detection Sent by:oauth-boun...@ietf.org Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The "state" parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the "state" parameter, to achieve the same goal? Probably the client already has a working "legacy" implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: "The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path" So this should be fine. Any comments? regards, Torsten. ___ 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
Re: [OAUTH-WG] draft 16 review notes
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 by the client. The authorization server MUST verify the scheme, authority, and path components of the redirection URI and SHOULD verify the query and fragment components. What does it mean for the authorization server to "verify the fragment component"? From: Eran Hammer-Lahav To: Brian Eaton , "oauth@ietf.org" Date: 04-07-11 01:25 PM Subject:Re: [OAUTH-WG] draft 16 review notes Sent by:oauth-boun...@ietf.org From: Brian Eaton Date: Sun, 22 May 2011 20:38:53 –0700 1.4.1 Authorization Code maybe expand the section on important security benefits. “The use of authorization codes also improves the ability to recover in the event of compromise of an application server or authorization server.” Can you explain? 4.2.1 Authorization Request Validation of the redirect_uri parameter is more important for the implicit grant type. Section 2.1.1 leaves registration of the redirect URI as “SHOULD”. It’s a “MUST” for the implicit flow. Suggested language: 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 authorization code matches a redirect URI pre-registered by the client. The authorization server SHOULD verify the scheme, authority, and path of the redirect URI. The authorization server MAY verify the query parameters as well. Changed it for now to: 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 by the client. The authorization server MUST verify the scheme, authority, and path components of the redirection URI and SHOULD verify the query and fragment components. I'm still not happy with this and want something stronger. 4.3.2 Access Token Request Really need language in here about the risk of brute force attacks on passwords. How about: Since this access token request utilizes the resource owner's password, the authorization server MUST protect the endpoint against brute force attacks. Section 10. Security Considerations There are various security risks mentioned in the OAuth WRAP security considerations that seem worth mentioning here: http://trac.tools.ietf.org/wg/oauth/trac/raw-attachment/wiki/SecurityConsiderations/OAuthWRAP2.0SecurityConsiderations.pdf Care to extract and edit for inclusion? Section 10.1 Client Authentication nit: “MUST NOT issue client passwords to installed apps” is a dead letter, it is not going to change standard industry practice in the slightest. The language from section 3 is more constructive. I’d suggest the following language for section 10.1 instead “The authorization server MUST NOT assume that native or user-agent based applications can maintain the confidentiality of client secrets.” That does conform with industry practice, so it’s more likely to be implemented. Do we have consensus for this change? Section 10.2 Client Impersonation I like the content of this section, but it seems to mix several different topics. - general risks of native applications - security considerations for “immediate mode”, where authorization requests are processed without end-user interaction. - validation rules for redirect URIs - open redirectors - access token design Most of those merit separate discussion. Need proposed text. 10.3 Access Token Credentials “When using the implicit grant type, the access token credentials are transmitted in the URI fragment, which can expose the credentials to unauthorized parties.” That’s basically FUD. This should be made much more specific. It falls into the general category of security considerations for redirectors and clients... Need proposed text. 10.9 Authorization Codes MUST be single use is a dead letter, because it requires atomic operations at scale. Even things like password changes are not atomic in user databases of moderate size. Authorization codes might be generated quite frequently (e.g. when “immediate mode” flows are used), so a MUST for an atomic operation is unreal
Re: [OAUTH-WG] Timely review request: pre-draft-17
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 initiating the protocol, the client registers with with the 3. Line 508 s/denote/denotes the client. The token denote an identifier used to retrieve the 4. In section 1.6, I still find it misleading to say: The refresh token is bound to the client it was issued to, and its usage requires client authentication. This still implies "public clients" can't use refresh tokens by way of the authentication requirement. I now understand the language in section 3 regarding an authorization server's discretion with client authentication, but I would propose either dropping ", and it's usage requires client authentication" above, or changing it to: The refresh token is bound to the client it was issued to. Authorization servers should require client authentication for private clients when a refresh token is presented. 5. Is section 3.1 still [[Pending Consensus]] ? 6. Section 4.1.1 Authorization Request and section 4.2.1 Authorization Request To protect against CSRF I believe the state parameter should be REQUIRED, unless someone can demonstrate a scenario where it is not used and CSRF is avoided by other means. Regards, Shane. From: Eran Hammer-Lahav To: OAuth WG Date: 05-07-11 03:13 PM Subject:[OAUTH-WG] Timely review request: pre-draft-17 Sent by:oauth-boun...@ietf.org I have started sharing my planned changes for 17: https://github.com/hueniverse/draft-ietf-oauth Change log: https://github.com/hueniverse/draft-ietf-oauth/commit/24a48f99c204331264028 f66708427961a1bc102#diff-3 My main focus right now is to clarify client types, registration, and identification, as well as tweak the registration requirements for redirection URIs. This is still very raw. However, I would very much like to get feedback about the following sections: 1.1.1. Client Types 1.2. Client Registration 2.1.1. Redirection URI In section 2.1.1, please note that it includes many new normative requirements, but in practice, they mostly boil down to the requirement to register a redirection URI for using the implicit grant type as well as using the authorization code with a public client (new term for describing client incapable of keeping secrets). I have turned the spec around, making registered redirection URIs the default, and using the parameter as an optional feature. Feedback is very much appreciated as we only have a few more days before I have to push out -17 and would like a few more eyes looking at the new text before published. I am still not ready to share changes to section 3. Also, I have a long list of additional changes raised on the list. Thanks, EHL ___ 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
Re: [OAUTH-WG] Extra "Authorization: Basic" lines in examples
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:31 PM Subject:[OAUTH-WG] Extra "Authorization: Basic" lines in examples Sent by:oauth-boun...@ietf.org In sections 4.1.3, 4.3.2, 4.4.2, and 6 of draft -20, the examples contain both the line “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” and credentials in the post body. For instance, the example from 4.3.2 is: POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW Content-Type: application/x-www-form-urlencoded;charset=UTF-8 grant_type=password&username=johndoe&password=A3ddj3w I believe that the “Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW” line should be deleted from all of these examples, as you either use Basic or credentials in the post body, but not both. Thanks, -- Mike ___ 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
Re: [OAUTH-WG] Using OAuth error_code to glean information from the server
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 less an attacker can ascertain from error messages the better. From: Mike Jones To: "oauth@ietf.org" Date: 13/12/2011 10:56 AM Subject:[OAUTH-WG] Using OAuth error_code to glean information from the server Sent by:oauth-boun...@ietf.org I recently received an inquiry regarding invalid_client vs. invalid_grant. It seems that there is a potential information disclosure in the specification with respect to how these error codes are used: invalid_client Client authentication failed (e.g. unknown client, no client authentication included, or unsupported authentication method). The authorization server MAY return an HTTP 401 (Unauthorized) status code to indicate which HTTP authentication schemes are supported. If the client attempted to authenticate via the "Authorization" request header field, the authorization server MUST respond with an HTTP 401 (Unauthorized) status code, and include the "WWW-Authenticate" response header field matching the authentication scheme used by the client. invalid_grant The provided authorization grant (e.g. authorization code, resource owner credentials, client credentials) is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client. If one uses invalid_client when the client is unknown and invalid_grant when the client credentials are invalid, then an attacker could deduce whether or not a particular client exists. First, do people agree that this is a potential information leak and that the leak is meaningful? If so, what mitigation might be suggested? For instance, might a server choose to use a single error code for both (and potentially other) cases? Thanks, -- Mike ___ 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
Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback requested
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
browser to authenticate and grant authorization. The authorization server
can (e.g. for manual delivery) display the azn code on the browser screen.
The resource owner in concert with the authorization server must ensure
secure timely delivery of the authorization code to the client without it
being leaked. The authorization code should have a short lifetime allowing
only sufficient time for the client to get and use it.
The client must exchange the authorization code for an access [and refresh]
token as soon as possible then securely store those for future use.
The safe and secure delivery of the authorization code to the client has
been discussed in several contexts including native mobile apps. Redirects
with custom URI schemes, backchannel delivery via notification services,
and manual delivery such as discussed above are all possible. The core spec
doesn't describe these variants in detail but there is no reason an
authorization server can't implement them.
Regards,
Shane.
From: Justin Richer
To: Gregory Prisament
Cc: oauth@ietf.org
Date: 12/01/2012 06:50 AM
Subject:Re: [OAUTH-WG] Manual Authorization Codes -- Help/Feedback
requested
Sent by:oauth-boun...@ietf.org
You definitely can do that with an app-specific password using the
resource owner password flow, but if you're already doing OAuth, why
would you want to?
The Device flow fell by the wayside not because people didn't see value
in it -- many do -- but nobody in the group was actively implementing
against it and nobody wanted to pick up editorship of it. David did us
the courtesy of at least capturing those parts of the protocol into a
document so that they wouldn't be lost entirely, but what it really
needs now is an editor to step up and see it through to completion. This
WG is planning to recharter or re-form or something in the near future,
and if there's a champion behind the Device doc (and someone willing to
do the actual work of editing the text), then we'll see it come up again.
-- Justin
On 01/11/2012 01:49 PM, Gregory Prisament wrote:
> Correction: Last paragraph should read:
> ... Do you think an authorization server could implement
> application-specific passwords, passing it off as the "resource owner
> credentials" grant type...
>
> On Wed, Jan 11, 2012 at 10:47 AM, Gregory Prisament
> wrote:
>> Thanks for the link, that's very similar to what I'm going for.
>>
>> Any idea why people lost interest in the Device Flow? It seems like a
>> useful option to have!
>>
>> Also, in doing some research, I came across Google's
>> "application-specific passwords", which seem to be another way to
>> solve this problem.
>> http://support.google.com/mail/bin/answer.py?hl=en&answer=1173270
>>
>> Any thoughts on application-specific passwords. Do you think an
>> authorization server could implement application-specific passwords,
>> passing it off as the "client credentials" grant type. Would that be
>> in spec?
>>
>> Cheers,
>> Greg
>>
>> On Tue, Jan 10, 2012 at 11:47 AM, Justin Richer
wrote:
>>> What you're describing is the Device Flow, which was pulled out of the
main
>>> document a while ago and now sits here, somewhat outdated and unloved:
>>>
>>> http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00
>>>
>>> In this, the app gives the user a short code that they enter into a
URL, do
>>> the authorization there, and get a short code back. It's effectively
the
>>> same as the auth code flow, but it does the dance without HTTP
redirects.
>>>
>>> -- Justin
>>>
>>>
>>> On 01/10/2012 02:23 PM, Gregory Prisament wrote:
Hello,
I am developing a REST API and trying to follow the OAuth 2.0 protocol
for authentication, and have a few questions for you good folks.
The use case I'm interested in is native applications (such as linux
command-line programs) that are unable or unwilling to involve a
user-agent. In this case, it seems redirection-based flows
("Authorization Code" and "Implicit Grant Types") are out! That
leaves "Client Credentials" and "Resource Owner Credentials".
"Client Credentials" do not seem appropriate because the client may be
installed on multiple machines and used by different resource owners.
"Resource Owner Credentials" COULD work, but I'd rather not require
the resource owner to reveal their username and password.
One solution, which seems reasonable to me, would be to extend OAuth2
to include another grant type called "Manual Authorization Code".
Using a web browser, the resource owner would login&authenticate
with the authorization server (using sessi
Re: [OAUTH-WG] A Scope Attack against OAuth 2.0
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 which scope is actually granted. The client needs to handle cases where that differs from what it originally wanted. From: Wenjie Lin To: oauth@ietf.org Date: 18/02/2012 12:12 PM Subject:[OAUTH-WG] A Scope Attack against OAuth 2.0 Sent by:oauth-boun...@ietf.org We describe an attack on OAuth 2.0 (draft-ietf-oauth-v2-23), called scope attack, provide a live-demo of the attack on Facebook, and propose a fix with discussions. Scope Attack OAuth authorization of services is associated with service agreement scope. For instance, Client provides an online game to User with a service agreement scope A: User authorizes Client to access his profile information and to post messages on his behalf. A malicious User can request for online game with service agreement scope A, manipulate the scope field, and change it to scope B: User authorizes Client to access his profile information. User can still play the games, yet Client can’t post messages on User’s behalf, as originally agreed. OAuth 2.0 authorization code grant and implicit grant are vulnerable to the scope attack. A Scope Attack Scenario (1) Authorization Server: Facebook (authorization code grant) (2) Client: Online gaming company Game. It allows User to play the games with the service agreement scope A: User authorizes Game to access his profile information and post messages on his behalf. (3) User: malicious User with an account at Facebook. He attempts to play the games yet without authorizing Game to post messages on his behalf, that is, he changes the scope from A to B: authorization of Client to access his profile information only. Attack Workflow (1) User requests Game (Client) for permission to play games, instantiating OAuth 2.0 with scope A. (2) Game generates an authorization request with a scope specification A, and redirects User to Facebook with the request. (3) User manipulates the scope field and changes it to scope B. The modified request is then sent to Facebook. (4) User grants the modified request. (5) Facebook redirects User back to Game with the authorization code. (6) Game exchanges the authorization code for an access token. However it has no knowledge that the scope A has been changed to scope B. (7) Game provides online gaming service to User. However, Game can’t post messages on User’s Facebook page. A Live-Demo: Facebook and CastleVille (IE and Safari tested) Step 1: Login Facebook and visit Facebook Apps and Game page https://www.facebook.com/games Step 2: Click CastleVille. Step 3: When you see the Request for Permission page, instead of clicking “Allow”, change the scope field in the URL from your browser from “scope=email%2Cpublish_stream%2Cpublish_actions” to “scope=email%2Cpublish_stream”. Step 4: After the modification, press ENTER to send the modified request to Facebook. Now you will see the modified Request of Permission page. Step 5: Click on “Allow” button and enjoy the game. (video: http://www.youtube.com/watch?v=zkmjLa3VU9w) Impact Client provides services to malicious User yet with the modified service agreement scope by User’s design. Manipulating Scope Field The scope field in access token response is required ONLY IF Authorization Server observes that the User authorized scope is different than the original scope. Consequently, User can manipulate the scope field so that Authorization Server cannot detect the change of the scope. As a result Client provides the services yet can’t obtain the information that is specified in the scope of the original service agreement. Client can verify the service agreement scope by checking all the fields against the original User request before providing the requested services to User. For instance, Client can verify the granted permissions if Authorization Server (e.g. Facebook) provides an API. However, this is out of the scope of OAuth 2.0, and Client may not check it. We observe: all top five games recommended by Facebook are vulnerable to the scope attack. Proposed Fix Draft-ietf-oauth-v2-23 Section 5.1: Change from “scope OPTIONAL, if identical to the scope requested by the client, otherwise REQUIRED.” to “scope REQUIRED” /* scope: User authorized scope */ Remarks (1) The proof of the correctness of OAuth with our proposed fix will be published in an article: “OAuth 2.0 – At
Re: [OAUTH-WG] Securing APIs with OAuth 2.0
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 server, but the answer may depend have same dependency on the implementation you use. Regards, Shane. From: Pete Clark To: "oauth@ietf.org" Date: 29/02/2012 06:50 PM Subject:[OAUTH-WG] Securing APIs with OAuth 2.0 Sent by:oauth-boun...@ietf.org Hey all, I've joined the list because I'd like to use OAuth 2 to implement security for a new set of REST APIs I'm developing for a client. I'm coding with PHP, but my questions are more general. Right now, there will be only one web site that uses the APIs, in a server-to-server fashion, and currently we don't have a need for a third party application to gain access to user data, such that a user would need to authorize that app. We do, however, want to have that ability down the road. My question is, can I still use OAuth 2 in some way to implement our first phase? From what I've read, it seems like the "client credentials" flow is the one I want to use for now. Can someone: 1) Confirm that that's what I should use for this first phase? 2) Point me to an implementation of this flow (in any language) that I could use or port to PHP? I've found some libraries for php but can't really tell, being new, if they offer the "client credentials" flow 3) Answer one more question.. Will using the client credentials flow now allow me to move to one of the user-authorizes-external-app flows down the road without having to reimplement or throw away the client credentials flow code? I apologize for all the questions, but these would really help point me in the right direction.. Thank you for reading! Sincerely, Pete ___ 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
Re: [OAUTH-WG] Issue token for another user
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:[OAUTH-WG] Issue token for another user Sent by:oauth-boun...@ietf.org http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-02#section-3.8 In order to achieve the use case above, how would the client (a.k.a the resource owner in this case) specify which user to authorize? Would the correct approach be to make a request to the Authorization Server with the grant type set to "client_credentials" and set the scope to user=user_id (where user_id would be the identifier for the user Bob)? -David ___ 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
Re: [OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients
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/sweeden/entry/mobile_oauth_application_demonstration https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood You'll see that a client secret is not required at all as native mobile clients are really public. My server is currently offline, but I'll be bringing it back up again in the next couple of days then you can try it our directly. From: "Stein Desmet" To: oauth@ietf.org Date: 13/03/2012 01:20 AM Subject:[OAUTH-WG] Client credentials flow vs. authorization grant flow for native clients Sent by:oauth-boun...@ietf.org I have mistakingly asked this question on the google group on google's Oauth2 implementation, so here it is at the correct place (I hope). We have an authentication server/identity provider, and a number of external web applications (ie resource servers) that make use of it. We would like to build native applications (iOS/Android) that make use of the resources on these web applications, so adding Oauht2 to both our authentication server and our web applications to provide authorization seems ideal. However, there is one issue: it is possible for end-users to authenticate themselves using smartcards or electronic ids (these users do not have a login/password at all). Therefore, we can't use embedded user-agents, or external user agents located on the mobile platform itself, so users would need to use a browser on another computer. However, I'm not entirely sure which flow is best applicable in such a case, and offers the best security? - The client credentials flow seems like a fit. Users would need to register their mobile device on the authentication server first, meaning they are issued a client id and secret, unique to each client instance. These credentials could be transferred in a number of ways, using QR codes, or have the user manually input them. - The authorization grant flow can also be used. The flow would be started on a separate browser using a helper web client app, and at the end of the flow, the authorization code is transferred to the native client by for example push notifications, QR codes or having the user manually input it. Client credentials in this case would be universal for the native application. This seems a bit harder to implement (and care must betaken to avoid exploitation of the web client app), but the refresh tokens could be used as OTP (i.e. issuing a new refresh token each time a user asks for a new access token, and invalidating the previous one), allowing some detection of misuse. The device flow seems applicable as well, but is no longer present in recent Oauht2 drafts (though there is still http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00). Best regards, Stein Desmet ___ 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
Re: [OAUTH-WG] Token refresh and The Two Generals
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 allow for the detection of a compromised refresh token (cloned client for example). If the legitimate client is not the first to use their refresh token it will fail when they do eventually try to use it. The likelihood of such a scenario or other implications of a lost refresh token is a different debate. Ideally the timeouts on the messages and the transport used for the refresh token exchange should be "reliable". If that is not the case then a mechanism such as suggested by Brian is possible, but ultimately not very clean as it means you really need to maintain at least two valid refresh tokens concurrently per initial grant and it gets messy. For example extending Brian's scenario, what would you do in response to #4? Return the same refresh token as #2? Return a new one and invalidate the one returned in response #2? From a server-side perspective you don't really know what the "right" thing to do is as you don't know the true state of the client. I would be inclined to optomise for the normal case and provided the error rate wasn't too high simply require a new initial grant when the app's refresh token gets out of sync. If the error rate is very high then I would consider a non-OAuth-standards-based more reliable transport mechanism for refresh token flows from the mobile, perhaps with a trusted piece of intermediary infrastructure to interface with the real authorization server using a standard flow. Regards, Shane. From: Tim Bray To: Brian Eaton Cc: OAuth WG , Bob Gregory Date: 27/11/2012 12:53 PM Subject:Re: [OAUTH-WG] Token refresh and The Two Generals Sent by:oauth-boun...@ietf.org As I read back through this one I’m not getting why you need a new refresh token. What am I missing? -T On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote: On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote: We've had OAuth2 running successfully for a while now, but we're finding that mobile applications have frequent problems with the refresh flow where a refresh request is made, but the network connection fails before the new AT/RT pair is received, leading to a "lost grant". In server-logs we can see that the token has been refreshed, and a new RT issued, but the client is stuck with the old invalidated RT. This problem has been reported by two separate client applications, both of whom are using a retry-mechanism for API requests since they expect an unreliable network connection. Does anybody have any guidance on this issue, or is there any work in an extension to address the issue of lost grants for token refreshes? Have you considered not revoking the old RT until the new RT has been successfully used? You might also need to consider what happens with requests that are in-flight at the time the old RT is revoked. For example: 1) client starts token exchange, hangs for some reason. 2) client starts token exchange, succeeds, receives new refresh token 3) client uses new refresh token 4) request 1 completes That could all happen in the space of a second or two. So you might want to think about not revoking the old token until you see the new refresh token used and a bit of time has passed. Cheers, Brian ___ 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 mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Token refresh and The Two Generals
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: 27/11/2012 10:33 PM Subject:Re: [OAUTH-WG] Token refresh and The Two Generals We did consider holding on to two refresh tokens, but it rapidly gets messy and degrades to using a single refresh token: since the old token won't be invalidated until the new one is used, a client can continue to use the old token indefinitely. After hurried conversation, we've decided that we will allow mobile clients to use a long-lived refresh token that does not expire on each request. This isn't our preferred option, since we have no way of detecting a compromised RT, but in order to obtain the RT an attacker must either a) Intercept the token in-flight by a MITM attack over SSL, which is non-trivial, or b) Obtain physical access to the client device, in which case it's game over anyway. We'll probably revisit this decision when we come to do another round of work on authentication, but for now this solves a user-experience issue that we're seeing in the wild, without seriously affecting real-world security. Thanks for your comments, I'll let you know if we find a way to de-messify the two-token solution. Yours, -- Bob. On Tue, Nov 27, 2012 at 3:22 AM, Shane B Weeden wrote: 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 allow for the detection of a compromised refresh token (cloned client for example). If the legitimate client is not the first to use their refresh token it will fail when they do eventually try to use it. The likelihood of such a scenario or other implications of a lost refresh token is a different debate. Ideally the timeouts on the messages and the transport used for the refresh token exchange should be "reliable". If that is not the case then a mechanism such as suggested by Brian is possible, but ultimately not very clean as it means you really need to maintain at least two valid refresh tokens concurrently per initial grant and it gets messy. For example extending Brian's scenario, what would you do in response to #4? Return the same refresh token as #2? Return a new one and invalidate the one returned in response #2? From a server-side perspective you don't really know what the "right" thing to do is as you don't know the true state of the client. I would be inclined to optomise for the normal case and provided the error rate wasn't too high simply require a new initial grant when the app's refresh token gets out of sync. If the error rate is very high then I would consider a non-OAuth-standards-based more reliable transport mechanism for refresh token flows from the mobile, perhaps with a trusted piece of intermediary infrastructure to interface with the real authorization server using a standard flow. Regards, Shane. From: Tim Bray To: Brian Eaton Cc: OAuth WG , Bob Gregory Date: 27/11/2012 12:53 PM Subject: Re: [OAUTH-WG] Token refresh and The Two Generals Sent by: oauth-boun...@ietf.org As I read back through this one I’m not getting why you need a new refresh token. What am I missing? -T On Mon, Nov 26, 2012 at 6:27 PM, Brian Eaton wrote: On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory wrote: We've had OAuth2 running successfully for a while now, but we're finding that mobile applications have frequent problems with the refresh flow where a refresh request is made, but the network connection fails before the new AT/RT pair is received, leading to a "lost grant". In server-logs we can see that the token has been refreshed, and a new RT issued, but the client is stuck with the old invalidated RT. This problem has been reported by two separate client applications, both of whom are using a retry-mechanism for API requests since they expect an unreliable network connection. Does anybody have any guidance on this issue, or is there any work in an extension to address the issue of lost grants for token refreshes? Have you considered not revoking the old RT until the new RT has been successfully used? You might also need to consider what happens with requests that are in-flight at the time the old RT is revoked. For example: 1) client starts token exchange, hangs for some reason. 2) client starts token exchange, succeeds, r
Re: [OAUTH-WG] OAuth mobile flow
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 seem to still want to do that). These might give you an idea: https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood http://www.youtube.com/watch?v=cLLrZMt_hII Regards, Shane. From: Security Developer To: OAuth@ietf.org Date: 25/03/2013 05:52 AM Subject:[OAUTH-WG] OAuth mobile flow Sent by:oauth-boun...@ietf.org Hi, Can any body please help in describing the OAuth flow for mobile applications? Thanks for your time.___ 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
Re: [OAUTH-WG] OAuth mobile flow
What I did in my OAuth 2.0 server environment was allow a client to self-register without a redirect URI. If they do that, then use the azncode flow, the azncode is displayed on the screen and the resource owner figures out for themselves how to get it to the client. Quite similar in principal to oob in OAuth 1.0 as you suggested. And yes - you can even try that pattern out for yourself on my demo OAuth server. Take a read of https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment for details on how to get yourself a client_id. I do some custom stuff for mobileClient - like shrink the authorization code to six lowercase chars and reduce it's lifetime to 60 seconds so it can be more easily typed into a phone keyboard, but ultimately that's just config. In my demos you saw two options for delivery - type it in, or scan it in via QR. Obviously there are several security and operational considerations to think about, but ultimately provided the resource owner does securely deliver the code to the client it's fundamentally ok. You can get more elaborate than that for mobile scenarios - for example you can use a web view of the mobile application itself to interact with the resource owner then send the azncode back via a push notification service. This has rouge app / password phishing implications that I don't like and is no better from a security perspective than doing resource owner password credentials flow with a public 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: > 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 seem > to still want to do that). > > These might give you an idea: > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_oauth_application_demonstration > https://www-304.ibm.com/connections/blogs/sweeden/entry/mobile_demonstration_under_the_hood > http://www.youtube.com/watch?v=cLLrZMt_hII This is interesting, thank you. I'm just wondering, how does you application decide that the access token is to be returned effectively out of band (which reminds me of the 'oob' redirect uri from OAuth 1.0). Looks like the client_id being equal to "mobileClient" (in your demo) is a hint. If yes, then would you (and others) see any benefit in actually attempting to get an 'oob' redirect_uri value standardized ? (sorry if this was already raised earlier). I can see how I can get a generic framework for supporting writing OAuth2 applications returning the code directly to the browser even without having 'oob' redirect uri - example, one can configure the authorization endpoint to recognize that a particular client_id requires an out of band delivery of the access token, etc. FYI, I like the device code flow you linked to though appreciate the simplicity of returning the token to the browser in demos, etc... Cheers, Sergey > > Regards, > Shane. > > > > From: Security Developer > To:OAuth@ietf.org > Date: 25/03/2013 05:52 AM > Subject: [OAUTH-WG] OAuth mobile flow > Sent by: oauth-boun...@ietf.org > > > > Hi, > > Can any body please help in describing the OAuth flow for mobile > applications? > > Thanks for your time.___ > 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 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
Re: [OAUTH-WG] OAuth mobile flow
The latest demo application I have actually has two modes of registration - the one that I show in the video is indeed the authorization code flow with manual delivery of the code however there is another registration panel which allows the resource owner to type in their U/P and then it does indeed use the resource owner password credentials flow with a public client id. The reason I chose that rather than simple client_credentials flow is that only the resource owner password credentials flow (and azn code) issues a refresh token which is central to the pattern. The rest of your discussion about public clients and the token endpoint authentication is accurate - it is essential that the resource owner securely deliver the authorization code to the client - this is really what is identifying that instance of the client. This is written up reasonably well in the threat model doc. 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 really which hopefully won't be off-topic, On 25/03/13 14:55, Shane B Weeden wrote: > What I did in my OAuth 2.0 server environment was allow a client to > self-register without a redirect URI. If they do that, then use the azncode > flow, the azncode is displayed on the screen and the resource owner figures > out for themselves how to get it to the client. Quite similar in principal > to oob in OAuth 1.0 as you suggested. And yes - you can even try that > pattern out for yourself on my demo OAuth server. Take a read of > https://www-304.ibm.com/connections/blogs/sweeden/entry/oauth_demonstration_environment > for details on how to get yourself a client_id. I do some custom stuff for > mobileClient - like shrink the authorization code to six lowercase chars > and reduce it's lifetime to 60 seconds so it can be more easily typed into > a phone keyboard, but ultimately that's just config. > > In my demos you saw two options for delivery - type it in, or scan it in > via QR. Obviously there are several security and operational considerations > to think about, but ultimately provided the resource owner does securely > deliver the code to the client it's fundamentally ok. You can get more > elaborate than that for mobile scenarios - for example you can use a web > view of the mobile application itself to interact with the resource owner > then send the azncode back via a push notification service. This has rouge > app / password phishing implications that I don't like and is no better > from a security perspective than doing resource owner password credentials > flow with a public client id, but again it's still a possibility. Why do you refer to the "resource owner password credentials flow" with a public client id ? I see that the resource owner does indeed authenticate and then authorizes a given mobile client application, but effectively it is an authorization code flow 'minus' the redirect from the confidential client (which the mobile app is not in this case), so the RO simply directly invokes on the authorization endpoint, omitting an otherwise required "redirect_uri" - which in itself is not a RO password credentials flow. As a side note I guess I also start appreciating how does a token endpoint can 'authenticate' a public client like 'mobileClient' without it also offering a password/etc, the assumption is that the code obtained earlier must've been provided to the mobile application securely, so effectively it is the (public) client_id + the grant (whatever it is, securely obtained by the client) that the token endpoint works with: I'm not sure yet if it can affect the common processing path in the token endpoint or not, probably not, because the public client must've been marked as such during the registration, so the token endpoint can accept a client_id only (without any credentials like password), as far as the authentication is concerned Thanks, Sergey > > 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: >> 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
[OAUTH-WG] Draft 16 comment
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 without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling "instance secret" for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
