It is good to see this RESTful authorization server (AS) discovery mechanism.
It takes me back to 2010 & 2011 when this idea was also discussed.
The "iss" value in the WWW-Authenticate response header should presumably be an
AS's real "iss" value, not an AS's token endpoint address.
So
H
Thanks, Torsten.
In 4.11, you can probably add client_secret and code phishing explained in
https://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
.
I do not like the mitigation strategy there at all, though. Now that we
have MTLS draft, using that is much better.
The curr
On 2017-11-14 10:27, Brian Campbell wrote:
> The expectation/assumption is that the SubjectDN would be a stable
> identifier through re-issuance of certificates, regardless of whether
> they be short or long term. We've had basically this as a product
> feature for years and use of the SubjectDN
Hi all,
I just published revision -04.
Changes:
Added best practices on Token Leakage prevention
Restructured document for better readability
kind regards,
Torsten.
> Anfang der weitergeleiteten Nachricht:
>
> Von: internet-dra...@ietf.org
> Betreff: [OAUTH-WG] I-D Action: draft-ietf-oauth-s
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol WG of the IETF.
Title : OAuth Security Topics
Authors : Torsten Lodderstedt
John Bradley
Thanks for the quick response Mike. Good to know I understand specs once in
awhile.
/Dick
On Tue, Nov 14, 2017 at 5:14 PM, Mike Jones
wrote:
> Good catch. The authorization_endpoint should only be required if flows
> are supported that need it. Our old favorite, the Resource Owner Password
>
The expectation/assumption is that the SubjectDN would be a stable
identifier through re-issuance of certificates, regardless of whether they
be short or long term. We've had basically this as a product feature for
years and use of the SubjectDN as the identifier hasn't been an issue. And
it's not
Good catch. The authorization_endpoint should only be required if flows are
supported that need it. Our old favorite, the Resource Owner Password
Credentials flow doesn’t use it, correct? Likewise, the Client Credentials
flow doesn’t. I’ll plan to make appropriate updates in -08.
Resurrecting the thread that had a request for more guidance around how to
use the explicit typing with nested JWTs. As discussed/requested during the
WG meeting.
On Mon, Jul 17, 2017 at 5:55 PM, Mike Jones
wrote:
> Good point. I’d had that thought as well at one point but failed to
> express i
I was reviewing https://tools.ietf.org/html/draft-ietf-oauth-discovery-07
and noticed that in
https://tools.ietf.org/html/draft-ietf-oauth-discovery-07#section-2
that authorization_endpoint
is REQUIRED.
I am working on deployments that are two-legged OAuth where there is
no authorization_endpoint
So I reviewed the security considerations text which basically sais
that the server can avoid being spoofed by managing its set of trust
anchors. The text is better than nothing.
However this lead me to ask another question about the use of
SubjectDN as an identifier for the subject in client met
11 matches
Mail list logo
