wrt section 4.1.3
The redirect_uri parameter should at least be required if the authz
server sent the authorization code to a redirect_uri passed in by the
client into the authorization request.
In this case, the authorization server must bind this uri to the authz
code and require the client
Hi all,
- 10 Security considerations
- 10.10 Session fixation...
Breno does not feel that session fixation is properly described nor
dealt with.
Breno is right. The threat that shall be prevented here is described
in the security threat document
Hi Doug,
Am 19.05.2011 04:09, schrieb Doug Tangren:
Followup questions from draft 16
1. On storing user password for the resource owner creds flow. If the
client stores a access token along with the refresh token [1] to
refresh it, there should be no need to store the users password as
Am 27.04.2011 17:35, schrieb Hannes Tschofenig:
In some sense you are right. The problem is just that this is the name of the
group :-)
http://datatracker.ietf.org/wg/oauth/charter/
Maybe we should adjust the name with the rechartering process.
I think we should.
regards,
Torsten.
On Apr
As to the question of interoperability, the fact that OAuth allows freedom of
choice to the AS for method of authentication makes this point moot. Would you
agree? (short of various providers could pooling together to standardize on an
auth method outside of the spec).
One possible
Hi all,
I just posted a new revision of the proposed text for the core draft's
security considerations section
(http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-02).
The text makes some strong statements wrt client secrets/authentication,
HTTPS, refresh tokens and
Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary):
According to section 6 Refreshing an Access Token (-13.txt), client when making a
request for exchanging a refresh token for an access token has to include its authentication
credentials, and the authorization server MUST validate the
new slide for my first part
Am 31.03.2011 21:13, schrieb Hannes Tschofenig:
After a chat with Blaine we have an updated agenda proposal:
First, we need to cover our working group items:
–draft-ietf-oauth-v2
•Security Consideration Section (Torsten)
•Error Code registry (Mike)
•Client
Hi all,
I just uploaded a proposal for the security section of the core spec to
the IETF site
(http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-securityconsiderations/).
As posted on the list previously, our idea was first to derive a
security consideration section for the core
I just uploaded a revised version incorporating most comments we
gathered today.
http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01
regards,
Torsten.
Am 31.03.2011 12:08, schrieb Torsten Lodderstedt:
Hi all,
I just uploaded a proposal for the security section
Hi Francisco,
Am 31.03.2011 20:59, schrieb Francisco Corella:
Hi Torsten,
We are discussing TLS right now as a mean to prevent
impersonation of the end-user's session on the client
site. Correct? It's definitely a good advice to protect
session from being highjacked that way. But I'm
We are discussing TLS right now as a mean to prevent impersonation of
the end-user's session on the client site. Correct? It's definitely a
good advice to protect session from being highjacked that way. But I'm
wondering whether this really belongs into the scope of OAuth?
BTW: It's covered
Hannes Tschofenig hannes.tschofe...@gmx.net schrieb:
That's what I thought was the plan. (Assuming the working group agrees to work
on a separate document. I would support it.) On Mar 27, 2011, at 10:03 AM, Eran
Hammer-Lahav wrote: So the new plan is for you to provide the text for the
Hi Phil,
looks even better now :-)
As already pointed out
(http://www.ietf.org/mail-archive/web/oauth/current/msg05599.html),
Have client credentials? No does not automatically imply usage of
implicit grant. The client could also use the authorization code (for
various reasons).
regards,
Here are my comments on this draft:
I repeat my proposal to name the URI parameter for passing the token
bearer_token instead of oauth_token. The same applies to the
respective body parameter. This is more inline with the I-D's terminology.
section 2.4
If the protected resource request does
pls. add a presentation about the security document/considerations to
the agenda
Am 15.03.2011 20:52, schrieb Hannes Tschofenig:
A reminder to send me your presentation request.
On Mar 14, 2011, at 9:13 AM, Hannes Tschofenig wrote:
Hi all,
the IETF meeting in Prague is just around the
Hi Peter,
Thursday is fine with me.
I'm also open to start the dicussion around the topic earlier in one of
the beer halls Igor mentioned :-)
regards,
Torsten.
Am 14.03.2011 10:10, schrieb Mark Mcgloin:
Can we rule out Friday afternoon as people will be getting return flights.
I am trying
Congratulation!
I've got some questions:
- do you support the token_type parameter for the revocation endpoint?
- where can one find a documentation of the native app support?
- what is your approach to native apps and client secrects?
regards,
Torsten.
Am 14.03.2011 20:35, schrieb Marius
Am 15.03.2011 14:34, schrieb David Robinson:
Page 4 of the specification says:
The client MUST NOT make any assumptions about the timing and MUST NOT
use the token again.
In the case of a self-care portal mentioned in - 1.0 Introduction -
clients may not be aware that
tokens have been
...@lodderstedt.net
CC: mark.mcgl...@ie.ibm.com,phil.h...@yahoo.com
A new version of I-D, draft-lodderstedt-oauth-security-01.txt has been
successfully submitted by Torsten Lodderstedt and posted to the IETF repository.
Filename:draft-lodderstedt-oauth-security
Revision:01
Title
Overall, I'm very happy with this draft. Excellent work, Eran!
A couple of comments though:
section 1.4: An authorization grant is a general term used to describe the
intermediate credentials ...
Since passwords represent authorization grants as well, I would suggest
to adjust the wording to
Hi all,
who of the WG will attend IETF-80 and during which days?
I'm uncertain yet whether it makes sense to arrive before Friday as
there is only a single OAuth session on this day. If others will be
available earlier we could probably setup some discussion of topics of
common interest,
Hi Craig,
I've been puzzling over this text in 4.2: ... the authentication of
the client is based on the user-agent's same-origin policy.
I consider this a a relict from the original User-Agent Flow
description. This flow was dedicated to JavaScript apps running
embedded in a webpage.
I would assume refresh token exposure to be less dangerous than the
leakage of uid/password since a refresh tokens is restricted to a scope.
regards,
Torsten.
Am 10.03.2011 20:22, schrieb Phil Hunt:
I think I was confused because of the use of the term credential rather than
token.
If you
Hi Phil,
that's great help for anyone looking for advice how to use OAuth.
One remark: In my opinion, the decision process for authorization code
vs. implicit grant involves more parameters.
refresh token required? -- authz code
client in question is a web application? -- authz code
client
Am 28.02.2011 23:58, schrieb Marius Scurtescu:
On Mon, Feb 28, 2011 at 12:16 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
+1
Igor
Torsten Lodderstedt wrote:
...
I'm in favour to add the refresh token parameter to the implicit grant
flow as it would make it more useable
this back in if others feel strongly about it, and will
take it in as part of the LC review process. I consider this purely editorial.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Saturday, February 26, 2011 5
Hi James,
I would expect the token to carry information about its issuer. Would
this be sufficient in order to detect CSRF?
regards,
Torsten.
Am 25.02.2011 01:08, schrieb Manger, James H:
Q. Should an OAuth client app list the authorization server in the
Origin header of requests to
I agree with your point of view.
Consequentely, the parameter name should be something like bearer_token?
regards,
Torsten.
Am 25.02.2011 20:49, schrieb Brian Eaton:
My two cents:
We've already taken three user visible outages because the OAuth2 spec
reused the oauth_token parameter in a way
Am 18.02.2011 18:40, schrieb Marius Scurtescu:
On Fri, Feb 18, 2011 at 3:49 AM, Mark Mcgloinmark.mcgl...@ie.ibm.com wrote:
Marius
Isn't the risk of the refresh token leaking the same as the risk of the
access token leaking, i.e. why not provide both?
Sure, but refresh tokens never die.
One
Hi all,
I just noticed a change between draft 11 and 13 I would like to bring to your
attention.
Until draft 11, the spec left open whether the client of the authz code grant
type had to present a secret or not. It had been a decision of the authz server
and I assume some deployments already
, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Am 12.01.2011 22:19, schrieb Richer, Justin P.:
Yes, let the server do the work. In practice, it's going to be looking up
the token based on the token value anyway (for bearer tokens, at least). All
the client really cares
also incorporate additional security text into each
grant section. But having one comprehensive security section makes the
other parts easier to read
EHL
*From:*Brian Eaton [mailto:bea...@google.com]
*Sent:* Monday, February 21, 2011 9:36 PM
*To:* Eran Hammer-Lahav
*Cc:* Torsten Lodderstedt; OAuth
Hi Francisco,
Am 22.02.2011 06:57, schrieb Francisco Corella:
Hi Torsten,
4.4.1.2. Threat: Eavesdropping authorization codes
The OAuth specification does not describe any mechanism for
protecting authorization codes from eavesdroppers when they are
transmitted from the Service Provider
Hi Hannes,
just submitted the document. I'm looking forward to a fruitful discussion.
regards,
Torsten.
Am 18.02.2011 13:34, schrieb Tschofenig, Hannes (NSN - FI/Espoo):
Hi Thorsten,
Hi all,
I am wondering what the status of the security draft is. The group is
eagerly waiting for it. I
Hi Brian,
Mark McGloin, Phil Hunt and I are working on a security considerations
document. We plan to submit it to the working group in the next couple
of weeks. Your contribution would be highly appreciated. What would you
like to contribute?
regards,
Torsten.
Am 07.02.2011 19:09, schrieb
Long introduction - here are the documents:
A) Simple Web Discovery (SWD)
http://www.ietf.org/id/draft-jones-simple-web-discovery-00.txt
I consider authorization server endpoints and capabilities discovery an
important aspect and would be willed to review.
B) HTTP Authentication: MAC
.
Torsten Lodderstedt said:
I would expect the WWW-Authenticate header to return all the data required to
obtain the credentials/tokens, such as
WWW-Authenticate: MAC realm=somerealm, tokenUrl=ytoken_secret=yes
WWW-Authenticate: BEARER realm=somerealm, tokenUrl=y
I don't really like
Hi Kristoffer,
Hannes compiled the list :-)
regards,
Torsten.
Am 07.02.2011 22:10, schrieb Kristoffer Gronowski:
Hi Torsten!
Great that you compiled the list on WG items.
IMO there is one item missing and that is to create an optional formal
interface between the authorization server and the
+1 for option 3, but would be fine with option 1, too
Both are quite similar, except 3 keeps the link between the OAuth
authorization server API (how to get a token) and the HTTP schemes used
to send the tokens to the resource servers. Since OAuth is becoming, in
my perception, the synonym
...@hueniverse.com]
Sent: Saturday, September 11, 2010 7:59 AM
To: Torsten Lodderstedt
Cc: Freeman, Tim; oauth@ietf.org
Subject: RE: [OAUTH-WG] Why give the redirect URI when trading an access code
for an access token?
Sorry.
7. Evil user takes the code and gives it back to the client
, such as password or
ticket for an access token. I mean the resource owner password flow is
already an example of such a flow.
regards,
Torsten.
-- Bob Gregory
On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
Zitat von
[mailto:oauth-boun...@ietf.org] On Behalf
Of Torsten Lodderstedt
Sent: Monday, January 24, 2011 1:10 PM
To: OAuth WG
Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
endpoint?
Hi all,
I'm currently thinking about the integration of existing HTTP
authentication schemes
done
Am 21.01.2011 06:38, schrieb Eran Hammer-Lahav:
Whoever is working on the security considerations section, please add this to
your list.
EHL
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Brian Eaton
Sent: Saturday, July 10, 2010
Of Torsten
Lodderstedt [tors...@lodderstedt.net]
Sent: Sunday, January 16, 2011 1:54 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters
Hi Eran,
you made some good points and I agree with most of your analysis. The way we
use BASIC in the current draft
using, say, Basic or Digest? Seems like a complex framework for
combining schemes into one header.
EHL
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Sunday, January 16, 2011 10:55 AM
*To:* Eran Hammer-Lahav
*Cc:* OAuth WG
*Subject:* Re: [OAUTH-WG] Removal: credential body
an existing client authentication scheme such as
Digest, your solution creates a conflict, unless we define a way to
combine grant + Digest into one header.
EHL
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Tuesday, January 18, 2011 10:36 PM
*To:* Eran Hammer-Lahav
*Cc
Hi Eran,
you made some good points and I agree with most of your analysis. The
way we use BASIC in the current draft is not perfect, mainly because it
is a compromise. It was basically the attempt to be more HTTP compliant
while still supporting the parameter-based approach.
I would
wouldn't that mean to drop section 6 completely?
regards,
Torsten.
Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav:
One of the main problems with OAuth in general has always been the
unsanitary mix of authorization and authentication (it's an
authentication protocol... authorization
+1 pro JSON
Am 16.01.2011 08:41, schrieb Eran Hammer-Lahav:
Why is the token returned in the fragment using form-encoding? This
makes no sense. It should be a JSON string for the following reasons:
1.All token responses should be the same, which will enable returning
structured responses
Am 12.01.2011 01:43, schrieb Brian Eaton:
On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Do you see any need to restrict the power of this token or is it as powerful
as the tokens obtained using the code? I'm asking because this token is sent
out without
at the real server?
Zachary
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 4:46 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token
+1 for option 2 because it will facilitates security analysis of the
protocol.
From a security analysis perspective, I think we need two views:
1) A structural view, describing the OAuth architecture (entities,
interfaces, communication paths) and
2) a flow-oriented view, which is built based
the intercepted signed request included
the hostname and port of the real resource server.
Zachary
*From:*Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
*Sent:* Wednesday, January 12, 2011 3:40 PM
*To:* Eran Hammer-Lahav
*Cc
From: Torsten Lodderstedt [tors...@lodderstedt.net]
Sent: Wednesday, January 12, 2011 4:07 PM
To: Richer, Justin P.
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on?
thank you for your feedback.
So you would suggest to let the authorization
Am 11.01.2011 06:44, schrieb Manger, James H:
- Authentication schemes
You propose to use the authentication scheme name OAuth2 for the
WWW-Authenticate header but another scheme name MAC for the
authorization header. I've never seen such an asymmetric approach before.
Don't you think people get
I just posted a new revision of
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/.
Please consider it for the re-chartering process.
Additionally, Mark and me are still working on the security document. It
takes longer time than expected because of the topic's inherent
the only difference I see is the code in the fragement will not show up
in HTTP referers.
Am 11.01.2011 22:21, schrieb Eran Hammer-Lahav:
But that's just an annoying implementation detail. If the only different now
between the hybrid and web server flows is one character ('?' vs '#'), and all
please include me on behalf of Deutsche Telekom
regards,
Torsten.
Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav:
In the next few weeks I plan to survey existing and planned
implementations of each feature of the specification and those
components without at least 3 interoperable (or
Independent of where this items belong to, the advice to only hand out
tokens to authenticated clients is stronger as required by the core
spec. There is a whole class of clients (native apps), which cannot keep
secrets
for the purpose of authentication.
Moreover, what is the benefit of
Hi Mike,
I've got some more comments on § 3.2 of your I-D.
paragraph 4: Encrypting the token contents is another alternative ...
How does token content encryption prevent the disclosure and abuse of a
token?
paragraph 5: For those rare cases where the client is prevented from
observing
the
Eran,
- Authentication schemes
You propose to use the authentication scheme name OAuth2 for the
WWW-Authenticate header but another scheme name MAC for the
authorization header. I've never seen such an asymmetric approach
before. Don't you think people get confused about that? Moreover, the
Hannes,
in my opinion, OAuth should stay a token-format independent protocol. So
intuitively, I would vote to work on this topic
within another group. Otherwise people might get the impression that
OAuth is directly tied to a certain token format.
regards,
Torsten.
Am 10.01.2011 10:19,
Francisco,
Torsten,
Another question: how does the server validate the
identity/authenticity of the client? In other words, what
does a malicious app prevent from using the URL and server
of another native app?
Let me rephrase your question (correct me if I'm wrong): can
a malicious native
Francisco,
the attack you described sounds very similar to session fixation
attacks. TLS (more specifically server authentication) is one way to
cope with spoofing in general (supposed the client has a reasonably CA
policy). So it should do in this case, too.
Validation of the redirect_uri
Francisco,
just to make sure I understood your paper correctly: even native clients
are required to have a backend server component, which receives the
authorization results and makes it available to the native client?
regards,
Torsten.
Hi all,
OAuth provides only weak security when used
+1
I have asked myself all the time why oob disappeared in OAuth 2.0?
Does Google use this feature?
regards,
Torsten.
Am 29.12.2010 23:53, schrieb Marius Scurtescu:
I would like to propose an OAuth 2 extension that helps native clients
close the loop after the approval page. The extension
+1
Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav e...@hueniverse.com:
I think the 'assertion' parameter should be moved into this draft and defined
there. This will also facilitate its proper definition and status (required,
singular, etc.).
EHL
-Original Message-
From:
section 5.1.5 Assertion
I expected the assertion flow to be replaced by a general extension
model for new grant types (as described in section 7.4)?
But the the current text in section 5.1.5. requires every new grant type
to use the assertion parameter. Thus it supports additional assertion
Am 13.12.2010 22:27, schrieb Marius Scurtescu:
On Mon, Dec 13, 2010 at 11:00 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
section 5.2
“The authorization server SHOULD NOT issue a refresh token when the access
grant type is an assertion or a set of client credentials.”
How shall
Hannes,
will it be possible to dial-in?
regards,
Torsten.
Am 09.11.2010 05:47, schrieb Hannes Tschofenig:
Hi all,
at yesterday's security session we discussed ways on what to provide in the
security consideration for the OAuth specifications.
The plan was to have another session on
analysis document?
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Torsten Lodderstedt
Sent: Sunday, November 07, 2010 3:04 PM
To: Hannes Tschofenig
Cc: ab...@ietf.org; r...@ietf.org; i...@ietf.org; sec...@ietf.org;
web...@ietf.org; x...@ietf.org
Hi all,
Mark McGloin and me have been working on OAuth 2.0 security
considerations for a couple of weeks now. Since we both cannot attend
the IETF-79 meetings, we would like to provide the WG with information
regarding the current status of our work. I therefore uploaded a
_preliminary_
Martin,
great to see you contributing to the WG!
One question came into my mind: How do the other grant types (assertion,
username/password, refresh token) fit into your abstractions? The grant
type used also depends on the client and its capabilities, so just
returning a single URL
Am 15.10.2010 19:52, schrieb David Recordon:
Hey Hannes, I'd like to at least explain my reasoning behind not
planning to go to the China meeting because it really isn't
restrictions around travel. This is likely inpolitic to say, but it's
because of how much of a waste of my time the LA
Prateek,
as I remember previous discussions, both design options (self-contained
short-living/one-time use tokens as well as random strings) shall be
feasible. So your contribution would helpful anyway.
regards,
Torsten.
Am 01.10.2010 18:36, schrieb PRATEEK MISHRA:
Torsten,
Brain
Thank you for your advice. The Oauth security considerations are not finished
yet. They will handle the issues you raised, too.
Regards,
Torsten.
Am 30.09.2010 um 01:33 schrieb PRATEEK MISHRA prateek.mis...@oracle.com:
I read through v10 from the perspective of an implementor, and it seemed
Am 27.09.2010 19:11, schrieb Anthony Nadalin:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core to be
complete, there are previsions to use SSL, if one needs to go beyond this then
a reference to the
Am 27.09.2010 22:53, schrieb Dick Hardt:
On 2010-09-27, at 11:25 AM, Torsten Lodderstedt wrote:
Am 27.09.2010 19:11, schrieb Anthony Nadalin:
What is needed is needed is the security considerations section complete, I
don't think that the signature specification has to be in the core
Am 25.09.2010 04:22, schrieb Eran Hammer-Lahav:
OAuth 2.0 is far from being published as an RFC. I estimate it is at
least 6 months away from reaching final IESG approval, if not a year.
This is mostly due to a significant effort needed in writing and
reviewing the security considerations
+1 for basic signature support
there is a need to protect end-users from token abuse by rogue resource
servers (see
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5, paragraph
3). Signatures based on a token secret is one way to prevent this kind
of attack.
Signature mechanisms
Am 18.09.2010 01:28, schrieb Kris Selden:
Secrets on native apps are good! The key is (no pun intended) that the secret
not ship with the app. Each client should register for its own client_id and
secret when it is installed on the client machine.
Maybe I'm missing something but...
If it
Default for client password authentication is HTTP BASIC (cf.
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-2.1)
regards,
Torsten.
Am 16.09.2010 15:52, schrieb mat...@gmail:
Hi experts,
I'm now developing OAuth2 server library in Ruby, rack-oauth2.
I have one question about
the user-agent flow with a native
application? Maybe the spec should suggest only the web server flow.
The device flow would also work, but that's not part of the core spec.
Marius
On Wed, Sep 15, 2010 at 2:47 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I'm wondering whether
I plan to work on that aspect. Do you (or someone else) want to contribute?
regards,
Torsten.
Am 14.09.2010 um 17:18 schrieb Mark Mcgloin mark.mcgl...@ie.ibm.com:
What about Security Considerations. I know some individuals have worked on
it in the past - does it need a WG to complete
it to say that
direct access token revocation is optional but, if supported, then all
associated assess tokens must also be revoked on a revocation of a
refresh token.
On Sun, Sep 12, 2010 at 4:13 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Stefanie,
thanks for your comments
(refresh) tokens are invalid.
= Is this requirement really a MUST?
I don't think so.
Any thoughts?
Regards,
Stefanie
Am 08.09.2010 00:21, schrieb Torsten Lodderstedt:
I just submited the first version of my I-D for token revocation.
Link:
https://datatracker.ietf.org/doc/draft
00:21, schrieb Torsten Lodderstedt:
I just submited the first version of my I-D for token revocation.
Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
The I-D proposes an additional endpoint, which can be used to revoke both
refresh and access tokens. The objective
, attaching it to the evil user's
account.
9. Evil user can now access victim user data on his client account.
This is basically a session fixation attack.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Saturday, September 11, 2010 1:01 AM
To: Eran
Doesn't step 7 require the evil user to know the client's secret?
Am 10.09.2010 17:06, schrieb Eran Hammer-Lahav:
1. Evil user starts the OAuth flow on the client using the web-server flow.
2. Client redirects the evil user to the authorization server, including state
information about the
I just submited the first version of my I-D for token revocation.
Link: https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/
The I-D proposes an additional endpoint, which can be used to revoke
both refresh and access tokens. The objective is to enhance OAuth
security by
+1
we just discussed the need for adding grant types in order support
Telekom-specific user authentication mechanisms. So this proposal comes right
in time :-)
regards,
Torsten.
Am 02.09.2010 um 23:27 schrieb Justin Richer jric...@mitre.org:
+1
I've never liked the notion of not being
was able to extract.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 14, 2010 2:33 PM
To: Brian Eaton
Cc: Kris Selden; Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] issuing new refresh tokens
On Tue, Jul 13, 2010 at 9:58 PM
(aggregated) or these may be verified and passed on,
there are cases where both are methods are used. So we have thought
about multiple tokens,, this winds up being more complicated and
traffic, the reason to not send directly is for user consent.
*From:* Torsten Lodderstedt [mailto:tors
defines how a protected resource can tell the client what
additional scope(s) are needed in order to make their request
successful. Standardizing the delimiter allows for this sort of
addition interaction.
--David
On Tue, Aug 24, 2010 at 10:41 PM, Torsten Lodderstedt
tors...@lodderstedt.net
Am 28.08.2010 20:48, schrieb David Recordon:
On Sat, Aug 28, 2010 at 11:38 AM, Torsten Lodderstedt
tors...@lodderstedt.net mailto:tors...@lodderstedt.net wrote:
I think a bit more then just defining the delimiter is required in
order to make things work as you described
seams option 2 took the lead by one vote.
1a II
1b I
1c
2 III
If no one objects by 08/29, I start writing the I-D based on option 2.
regards,
Torsten.
Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
Hi all,
I intend to submit a I-D for token revocation. Based on previous
discussions
--- p.6 terminology/authorization server
A server capable of issuing tokens after successfully
authenticating the resource owner and obtaining authorization.
The authorization server may be the same server as the resource
server, or a separate entity.
Based
security issues?
Another drawback is that the access token response has to be extended.
What kind of modifications of tokens do you have in mind? (as you commented
with 1c)
Regards,
Stefanie
Am 16.08.2010 23:09, schrieb Torsten Lodderstedt:
Hi all,
I intend to submit a I-D for token revocation. Based
What data shall the issued token contain? Different identifiers and
also information about the different issuing authorities? Is the new
token's data inherited from the source assertions or are the assertions
just verified and the token data (incl. identity) are from other sources?
What do
701 - 800 of 975 matches
Mail list logo
