chive.ietf.org/arch/msg/oauth/cN0uYaEd5uOLEprCwc-0wJjKJfs/
> in 2020 but these discussion did not lead to anything in RFCs or drafts.
>
> Why?
>
> I think that if developers can register an URL to their native mobile app
> then they should do that.
>
>
>
> Kind
Isn't that covered by Token Exchange already?
https://datatracker.ietf.org/doc/html/rfc8693
Le sam. 18 mai 2024, 16:29, Igor Janicijevic a écrit :
> Dear All,
>
>
>
> I have published an Internet Draft document that I would like to introduce
> to the OAuth working group for consideration. Here i
That's a bit extreme. Can't an admin just unsubscribe him?
Cc: oauth-ow...@ietf.org
Le dim. 5 mai 2024, 21:57, Warren Parad
a écrit :
> I just marked it as spam, so his domain can deal with that. If everyone
> does it, the domain may be permanently denylisted.
>
> On Sun, May 5, 2024 at 9:50 PM
rowsing context" or possibly "code executed in a
document context" (or just "in a document"?), as opposed to a "worker
context" or service worker.
Anyway, thanks for that work. I'm only using the drafts as reference in
architecture discussions and am looking forw
tions consider the usage of PKCE as enough protection from
>> Login-CSRF and do not use state or nonce (for example this blog entry by
>> Daniel Fett
>> https://danielfett.de/2020/05/16/pkce-vs-nonce-equivalent-or-not/
>> suggests, that n
ional defences.
>
+1, just mentioning that there should be CSRF mitigations in place should
be enough IMO.
Also maybe mention that securing the API is then actually outside the scope
of the BCP (whose role in this case is only to recommend *not* using OAuth)
--
Thomas Broyer
/tɔ
Hi all,
Someone's apparently sending spam through this list using my email address
as the sender.
I'm obviously not the author of those.
Could some of you please send me the full spam mail (with full mail
headers) ?
Thank you in advance and sorry for the inconvenience but I don't think I
can do
information to begin
> with, so relying on an attacker "guessing" it should not be seen as a
> security countermeasure. This section of RFC7009 will be referenced in a
> subsequent errata.
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary,
On Sun, Oct 4, 2020 at 6:55 PM Nicolas Mora wrote:
> Hello,
>
> Le 20-10-04 à 11 h 27, Thomas Broyer a écrit :
>
> > There might be some kind of pushed events between the AS and the RS
> when
> > a JWT AT is revoked, to allow the RS not to introspect a JWT AT
Disclosure: I have not read the draft on JWT AT, those comments are based
only on my current knowledge of OAuth 2.0 / OpenID Connect, and JWT.
Le sam. 3 oct. 2020 à 19:18, Nicolas Mora a écrit :
> My 2 cents,
>
> Le 20-10-02 à 18 h 19, Andrii Deinega a écrit :
> >
> > Here is what I would like t
Hi Megan,
On Thu, Jul 11, 2019 at 5:18 AM Megan Ferguson wrote:
> Hi Jan,
>
> Please note that this errata report has been removed. As stated at
> https://www.rfc-editor.org/errata.php:
>
> "Errata are for the RFCs as available from rfc-editor.org."
>
Well, fwiw, the issue is also present in
h
On Wed, May 8, 2019 at 9:38 AM Emond Papegaaij
wrote:
> In our case or AS might have to federate the authentication to some other
> AS,
> that would only work in an iframe. Therefore, I think we will go for the
> OIDC
> prompt=none in a hidden iframe. I'm not sure what to do if the AS reports
> t
y) allows for extensions
> like resource indicators and token exchange to have multiple instances of a
> parameter value without having to invent some new scheme to encode or
> delimit multiple values.
>
> On Mon, Apr 22, 2019 at 7:52 AM Thomas Broyer wrote:
>
>> RFC6749 make
: [ "val-1", "val-2" ]
> }
>
> Apart from custom params, the resource indicators spec also suggests that
> such situations can occur:
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-02#section-2
>
> Thanks,
>
> Vladimir
> __
Yes, that was with the default cookie policy (on a coworker's macbook, and
he doesn't use safari as his main browser)
On Wed, Nov 28, 2018 at 11:20 AM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> with the default cookie policy?
>
> > Am 23.11.2018 um
Just tested my OpenID Connect Session Management implementation with Safari
12.0.1 and it works like a charm.
On Thu, Nov 22, 2018 at 8:09 PM George Fletcher wrote:
> My understanding is that cookies are not blocked on redirects
> (IPT2/Safari) but I haven't done extensive testing. So from a ful
On Thu, Nov 22, 2018 at 5:50 AM Torsten Lodderstedt
wrote:
> Hi George,
>
> > Am 20.11.2018 um 22:15 schrieb George Fletcher :
> >
> > OIDC provides a "prompt=none" mechanism that allows the browser app to
> request a new token in a hidden iframe. OAuth2 doesn't describe this flow..
> Note that f
Fwiw, this is something I thought about for Ozwillo but never ended up
implementing (though that still could happen): always issuing a refresh
token (vs. only when scope includes offline_access nowadays) but bind its
lifetime to the session when not offline_access. I would then revoke the
refresh t
On Mon, Sep 17, 2018 at 3:46 PM George Fletcher wrote:
> Hi,
>
> It appears that RFC 6749 and RFC 6750 are inconsistent in regards to the
> HTTP status code that should be returned when a requested scope is
> "invalid".
>
> For example, if a call is make to the /token endpoint to obtain a new
> a
Le mar. 10 juil. 2018 21:55, Andres Torres a écrit :
>If the issuer identifier value contains a path component, any
>terminating "/" MUST be removed before inserting "/.well-known/" and
>the well-known URI suffix between the host component and the path
>component.
>
>
> Just as cl
IFF the server processes it!
RFC 7009 says “An authorization server MAY ignore this parameter,
particularly if it is able to detect the token type automatically.” which
BTW is exactly my case.
For months, my AS received requests with token=Array, and now receives
requests with token=null. Those ar
To my knowledge, it's been replaced with RFC 8252.
See https://developers.google.com/identity/protocols/OAuth2InstalledApp (notice
the deprecation notices in options 3 and 4 in the "create authorization
credentials" section; you can find the "oob" URN later in the doc,
associated with the same opt
Are you looking for Token Introspection?
https://tools.ietf.org/html/rfc7662
On jeu. 24 août 2017 00:21 Malla Simhachalam
wrote:
> Hi,
>
> We have an OAuth token revocation specification to revoke consents from an
> external/relying party with a given token. I am wondering if there's a
> specifi
Rejecting a GET with code in the URL means that the code is never "used" at
the AS, so can still be exchanged for an access token; and rejecting the
request does not mean it won't leak. So reject if you like from the user's
point of view, but "consume" the code anyway (and then immediately revoke
t
Wouldn't expired_token be appropriate here?
On Wed, Jul 5, 2017 at 12:02 PM Chris Needham
wrote:
> Hi,
>
> I'm one of the contributors to the ETSI Cross Platform Authentication spec
> [1], which was based on an early draft of the OAuth 2.0 Device Flow.
>
> One of the things we found useful, and
On Wed, May 31, 2017 at 12:01 PM Jaap Francke
wrote:
> Hi all,
>
> It’s only since recently that I’m sticking my nose deeper into the various
> OAUTH (draft) specifications.
> I also recently joined this mailing list.
> I have a question and I hope someone can help me.
>
> I’ve been looking for a
The client app could (and should) do a window.location.replace or
window.history.replaceState to remove the entry from the browser history.
AFAICT, this is out of scope of the OAuth specs because they're about the
protocol and interactions between the parties involved, not about securing
each one o
it leaked and the attacker reinjected the leaked value, and b) the
client didn't invalidate the value after first use in step 1.
> Am 23.04.2016 um 15:53 schrieb Thomas Broyer:
>
>
>
> On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wr
On Sat, Apr 23, 2016 at 12:57 PM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi Guido,
>
> do I get it right. The attacker is supposed to use the state value in
> order to overwrite the user agent's session state?
>
Most apps only ever remember a single access token, so by re-using th
On Sat, Apr 23, 2016 at 12:49 PM Guido Schmitz wrote:
> Hi Torsten,
>
> as the state value is supposed to protect the user agent's session
> against CSRF attacks, an attacker can use the leaked state value to
> perform a CSRF attack against this user agent.
>
> The attacker can, for example, redi
Note that goal #2 is already taken care of by introspection (endpoint
varying response depending on authenticated client/RS), so maybe should be
refined here.
Le jeu. 17 mars 2016 18:44, George Fletcher a écrit :
> Goals:
>
> 1. Help the client not send a token to the "wrong" endpoint
> a. w
On Fri, Mar 18, 2016 at 1:50 PM George Fletcher wrote:
> I was thinking of goal #2 as addressing the issue of audience in the
> token. If the RS "authenticates" itself when calling introspection, then
> the AS could apply the audience restriction for the RS. Is that what you
> were thinking?
>
Y
n exchange and keep track
of both tokens.
> — Justin
>
> On Mar 15, 2016, at 12:34 PM, Thomas Broyer wrote:
>
>
>
> On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin
> wrote:
>
>> Hi
>>
>> After following the recent thread on multiple authoriza
On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin
wrote:
> Hi
>
> After following the recent thread on multiple authorization servers, but
> also reading some other related threads, I have a question related to
> when the token introspection can be avoided.
>
> My understanding has been that given
On Sun, Mar 13, 2016 at 2:03 AM Justin Richer wrote:
> What we've done in deployments is to combine JWT and introspection. You
> have all of your servers issue signed JWTs that include the "iss" (issuer)
> in the body, signed with the key of the AS. The tokens also include a
> random "jti" field.
On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin
wrote:
> This is not discovery, its simply metadata, […], I don’t understand the
> rush to get this document out when we already know it’s incomplete
>
+1
___
OAuth mailing list
OAuth@ietf.org
https://www.
I agree with Samuel's comments wrt jwks_uri and registration_endpoint; and
support the name change to “OAuth 2.0 Authorization Server Discovery
Metadata” (or possibly “OAuth 2.0 Authorization Server Discovery”; but I'd
rather narrow down the scope to only talk about metadata, without discovery
mech
Should the act and may_act also be registered for Introspection Endpoint
responses?
Le ven. 4 mars 2016 21:13, Brian Campbell a
écrit :
>
> A new draft of "OAuth 2.0 Token Exchange" has been published addressing
> review comments on the prior draft. The changes from -03 are listed here:
>
> http
On Mon, Feb 29, 2016 at 11:35 PM Brian Campbell
wrote:
> +1 for "OAuth 2.0 Authorization Server Discovery” from those two options.
>
> But what about "OAuth 2.0 Authorization Server Metadata”?
>
> The document in its current scope (which I agree with, BTW) isn't really
> about discovery so much a
On Thu, Feb 25, 2016 at 4:25 PM George Fletcher wrote:
> Interesting... this is not at all my current experience:) If a RS goes
> from v2 of it's API to v3 and that RS uses the current standard of putting
> a "v2" or"v3" in it's API path... then a token issued for v2 of the API can
> not be sent
Hi Nat,
On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura wrote:
>
> 2016年2月22日(月) 18:44 Thomas Broyer :
>
>
>> (well, except if there are several ASs each with different scopes; sounds
>> like an edge-case to me though; maybe RFC6750 should instead be updated
>> with
Couldn't the document only describe the metadata?
I quite like the idea of draft-sakimura-oauth-meta if you really want to do
discovery, and leave it open to implementers / to other specs to define a
.well-known URL for "auto-configuration".
The metadata described here would then either be used as-
Fwiw, French govt's FranceConnect, which uses OpenID Connect, has sample
apps using web views, and not using PKCE :-( (haven't looked in more
details; don't know whether their AS supports PKCE).
I just implemented PKCE in Ozwillo 10 days ago after reading this doc. I
still have some work to do to p
Le dim. 14 févr. 2016 02:40, William Denniss a écrit :
> On Sat, Feb 13, 2016 at 12:19 PM, Mike Jones
> wrote:
>
>> It's an acceptable fallback option if the working group decides it
>> doesn't want to register the values that are already in production use at
>> the time we establish the registr
So, you just removed every relationship to OAuth (and the note about OAuth
and authentication seems a bit out of context), and I thus wonder why the
OAuth WG would adopt this draft; that'd rather be a JOSE thing.
Le ven. 12 févr. 2016 07:03, Mike Jones a
écrit :
> This draft of the Authenticatio
On Wed, Jan 27, 2016 at 1:54 PM George Fletcher wrote:
> The difference might be whether you want to store the scope consent by
> client "instance" vs client_id application "class".
>
Correct me if I'm wrong but this only makes sense for "native apps", not
for web apps, right?
(of course, now wi
ts per client_id per user, and we have a
> > separate database object for storing them. I wouldn’t recommend simply
> > updating an access token that’s already in the wild with more power —
> > that just sounds wrong.
> >
> > — Justin
> >
> >> On Jan 26,
Fwiw, at Ozwillo, we track grants per user per client_id (we don't support
native apps; only web flows for now), and we don't do "incremental grants"
like Google: if you request scope B and the user had only granted scope A,
you'll get a token for scope B only. This is partly because our tokens are
Hi John,
Le jeu. 21 janv. 2016 15:42, John Bradley a écrit :
> We merged the state verification in with this rather than forcing people
> to also look at the JWT encoded State draft.
> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.
>
> While JWT encoded state is how I would
Or just account for clock differences when comparing values, which I
believe is what the specs suggest.
Le ven. 22 janv. 2016 15:50, Ben Bucksch a écrit :
> Story: We wrote a script implementing JWT.
>
> The code was working for my colleague, who wrote the script, but I just
> got "Invalid authe
Also, this is not news:
http://securityintelligence.com/spoofedme-social-login-attack-discovered-by-ibm-x-force-researchers/
On Wed, Apr 22, 2015 at 5:02 PM Justin Richer wrote:
> This seems to be not a problem with OAuth but with misusing OAuth as an
> authentication protocol:
>
> http://oauth.
I have one implementation (docs should be made public very soon), and we've
also made https://github.com/pole-numerique/oasis-php-integration (repo
will soon be renamed) as a client to the API for implementers of RPs in PHP.
Le mer. 28 janv. 2015 12:36, Hannes Tschofenig
a écrit :
> Hi Justin, H
Hi,
A couple editorial remarks:
When introducing the first 2 examples, maybe merge the two paragraphs,
starting with "The following non-normative example shows …".
Similarly, you talk about line wraps for display purpose but the examples
don't need/use wrapping.
Other than that, ready to go to
A few notes on the "form" only (not the "content"):
HTTP no longer is RFC 2616, it's RFC 7230 through 7237 (7235 and 7236
actually replacing 2617). Specifically, the GET and POST methods are
defined in RFC 7231.
application/x-www-form-urlencoded refers to RFC 1866; the same media type
is said to
On Tue Dec 02 2014 at 19:53:27 Richer, Justin P. wrote:
> Thomas, thanks for the review. Responses inline.
>
> On Dec 2, 2014, at 11:08 AM, Thomas Broyer wrote:
>
>
> The methods of managing and
>validating these authentication credentials are out of scope of th
So what?
The request is OK (no missing parameter, etc.) so a 400 is not appropriate
(it could still be used, but you couldn't tell what went wrong without
*also* having some well-defined error response document format; and an
"invalid_token" error code wouldn't work if you're also using token
auth
Hi,
Here are some notes about draft-ietf-oauth-introspection-01.
Background: I have implemented and deployed -00 (actually that was some
version of the individual draft, before it got adopted by the WG),
currently with only a couple "clients" (out of 20 or so OAuth 2.0 clients
currently, only a co
k one alternative to an introspection service is a revocation status
> service.
>
> But it is often not needed if token lifetimes are small (minutes /
> session life) compared to the refresh token which might last much longer.
>
> Again having info on the case helps explain th
Try it where? When you're the RS trying to determine whether you should
accept the token or reject it?
Le 30 juil. 2014 02:49, "Mike Jones" a écrit :
> Yes, but that’s the simplest thing to determine – try the token and see
> whether it works or not.
>
>
>
> *F
-- Mike
>
>
>
> *From:* OAuth [mailto:oauth-boun...@ietf.org] *On Behalf Of *George
> Fletcher
> *Sent:* Tuesday, July 29, 2014 3:25 PM
> *To:* Phil Hunt; Thomas Broyer
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAu
and, approval, or they've been blacklisted,
etc.), and the "iat" and "exp" claims so they could possibly refuse access
if the token is not recent enough or will expire too soon.
In due course, we'll probably add "amr" and/or "acr" claims (or s
yet on the reasons for an interoperable standard.
>
> Phil
>
> On Jul 28, 2014, at 17:00, Thomas Broyer wrote:
>
> Yes. This spec is of special interest to the platform we're building for
> http://www.oasis-eu.org/
>
>
> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofeni
___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
014 21:32, "Nat Sakimura" a écrit :
> Is it? Apart from the implicit grant that does not use token endpoint, all
> other grant references section 5.1 for the response, i.e., all shares the
> same response.
>
>
> 2014-07-23 15:18 GMT-04:00 Thomas Broyer :
>
>> I
"no_access_token" grant type. I do not consider this a
>> good idea as it changes the semantics of the token endpoint (as already
>> pointed out by Thomas). This endpoint ALWAYS responds with an access token
>> to any grant type. I therefore would prefer to use another endpoin
t;not using the token endpoint" because the token endpoint
> copy-pasted and renamed the authentication endpoint.
>
> -- Justin
>
> On Jul 23, 2014, at 9:30 AM, Thomas Broyer wrote:
>
> Except that these are about not using the Token Endpoint at all, whereas
> the curr
w grant type in
> order to implement the same flow.
> >>
> >> Phil
> >>
> >> On Jul 22, 2014, at 11:35, Nat Sakimura wrote:
> >>
> >>> +1 to Justin.
> >>>
> >>>
> >>> 2014-07-22 9:54 GMT-04:00 Richer, Justin P. :
&g
ft.
>
Thanks.
How about "pwd" then? I fully understand that I should return "pwd" if the
user authenticated using a password, but what "the service if a client
secret is used" means in the definition for the "pwd" value?
(Nota: I know you're at IE
The end of section 2.2 talks about prompt=consent but the value is not
defined above.
Also, I don't understand the note about "pwd" being used by a service. In
which scenario would that happen?
Finally, what's the difference between providing several values for "amr"
with and without including "m
from the refresh token; you can just
consider the access token returned by the token endpoint as issued from the
refresh token returned at the same time) .
If you send the access token for revocation, then only the access token
will be revoked.
Did I miss something?
--
Thomas Broyer
/tɔ.ma.b
I thought someone mentioned it already: in the example you might want to
send the request to /introspect instead of /register. It would be good to
see user_id returned in the example too to get a better sense of what it
really means (as I understand it, it's the username the user uses to sign
in al
FWIW, we return unauthorized_client.
Le 31 janv. 2014 18:06, "Todd W Lainhart" a écrit :
> > ...what's the intended way that the "request is refused and the client
> is informed of the error" when the the token was not issued to the client
> making the revocation request?
>
> We return an error_c
Le 3 déc. 2013 12:56, "Andreas Kohn" a écrit :
>
> Hi,
>
> the current RFC for OAuth 2.0 (http://www.rfc-editor.org/rfc/rfc6749.txt)
is very unclear on *how* to return the scope in the access token response
if there are multiple scopes requested/returned.
I think it's very clear, on the opposite.
the Client is expected to
use, but that could also have been "negotiated" before (just as with
jwt-bearer, you have to know what the AS expects you to use).
A compromised PR, despite knowing the access token (unless the JWT is
encrypted
Le 25 oct. 2013 19:28, "Torsten Lodderstedt" a
écrit :
>
>
> Am 25.10.2013 11:19, schrieb Thomas Broyer:
>>
>>
>>
>>
>> On Thu, Oct 24, 2013 at 7:50 AM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
>>>
>>> Hi
On Thu, Oct 24, 2013 at 4:36 PM, Richer, Justin P. wrote:
> On Oct 23, 2013, at 5:27 PM, Thomas Broyer
> wrote:
>
> On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. wrote:
>
>> Hi Thomas,
>>
>> You're right in that the introspection process is about g
sion
> of this threat ( http://tools.ietf.org/html/rfc6819#section-4.6.4).
>
Thanks for the pointer. I had already read that RFC but somehow forgot
about some details, and failed to check it back for that particular problem.
--
Thomas Broyer
/tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/&g
On Wed, Oct 23, 2013 at 8:37 PM, Eve Maler wrote:
> Hi Thomas-- You may want to take a look at UMA, which leverages both OAuth
> and Justin's token introspection draft. Token introspection on its own is a
> "shallow" kind of loose coupling between authorization servers and resource
> servers. If
On Wed, Oct 23, 2013 at 9:22 PM, Richer, Justin P. wrote:
> Hi Thomas,
>
> You're right in that the introspection process is about getting meta
> data about a particular token by making an authenticated call. It does
> reveal a lot of information about the token -- because that's exactly the
> p
information returned? I understand that this is just a
framework and each server would have its own rules, but you're then either
saying too much or too few.
Thanks in advance for any guidance about how to achieve my goal. Should I
go with introspection? (maybe I misunderst
80 matches
Mail list logo
