On 2023-04-18 02:51, Vittorio Bertocci wrote:
Hi Evert,
The audience parameter isn’t standard- it was implemented before a
standard modeling the corresponding concept (resource indicators) was
introduced in
https://www.rfc-editor.org/rfc/rfc8707.html.
Audience is mostly an alias of the resour
Hi list,
I'm the author a OAuth2 client library[1]. I received a feature request
to support the "audience" parameter on client_credentials, as seen on
the following two server implementations:
* Auth0:
https://auth0.com/docs/api/authentication?http#authorization-code-flow-with-pkce45
*
I hope this is not inappropriate for this list, but I wrote a new OAuth2
library for JS/TS:
https://github.com/badgateway/oauth2-client
Some highlights:
* 3KB compressed / 0 dependencies
* Works on Node and in browsers.
* Supports the server meta-data document, PKCE, Token introspection
I hop
On 2021-05-15 11:35 a.m., Filip Skokan wrote:
Hello Vittorio, Brian, everyone
This is a followup to my feedback in the TMI BFF interim meeting on
April 26th where I mentioned I'd bring this to the list for discussion.
I proposed an alternative to using fixed endpoint locations and/or
discov
ice if some other component is generating the emails as it
needs no coordination with the AS.
— Neil
On 2 Mar 2021, at 19:04, Evert Pot wrote:
Dear list,
We have a requirement to let users log in to an application via a
code sent by email.
This code needs to be exchanged for an access/refres
Dear list,
We have a requirement to let users log in to an application via a code
sent by email.
This code needs to be exchanged for an access/refresh token pair, and
should only work once.
The access/refresh token scope would give limited access to the
application. Since we already use the
On 2021-02-25 3:41 a.m., Seán Kelleher wrote:
Yep, this is the big point - OAuth is designed to require the the
third leg of trust that creates the NxM problem.
I believe the snippet of Justin's that you quoted actually shows you
how you can forgo the trust element using dynamic clie
On 2021-02-25 3:22 a.m., Seán Kelleher wrote:
Just to clarify, I assume in this discourse that the "server" in this
client and server relationship refers to an AS/RS pair in OAuth
terminology? Based on this, one big sticking point for me on the
applicability of NxM, or even 1xM, is that all of
If every client and every server needs to implement "/all the popular
mechanisms/" then that's not such a big deal when you're shipping the
client code for your own server as part of a website, but it's a big
deal if you're trying to create a general client and don't want to
have to hard-code
On 2020-05-10 10:20 a.m., Aaron Parecki wrote:
> Hi Beena,
>
> This sounds like a great use of the client credentials grant. The
> password grant is being removed from OAuth 2.0 by the Security Best
> Current Practice. Can you clarify what you've found useful about the
> password grant that the cl
Currently OAuth 2 uses application/json as their main mimetype for JSON
responses.
This has at least two drawbacks:
1. Content-negotiation is a good way to to version/alter behavior of
endpoints/introduce extensions or modifications.
2. In systems that use Web Linking, it's harder to use a
At our company we're developing REST apis.
One of the things that are pretty important to us, is developers being
able to access the REST apis directly, via their browsers.Our systems
typically have a middleware that converts generated hal+JSON to a HTML
interface for easily browsable.
When using
On 2019-05-06 2:35 p.m., Neil Madden wrote:
> I don’t know the relative merits of Link headers vs .well-known, but
> there is at least one other draft standard I know of that is going
> down the .well-known route for this kind of thing (password changes in
> this case):
>
> https://github.com/WICG/
Hi Benjamin,
Thanks for the hint. Will give that a shot!
Evert
On 2019-05-06 1:38 p.m., Benjamin Kaduk wrote:
> Hi Evert,
>
> On Thu, May 02, 2019 at 11:41:50PM -0400, Evert Pot wrote:
>> Hi everyone!
>>
>> I've been running into a number of situations where it
Hi everyone!
I've been running into a number of situations where it would have been
beneficial to have a few protocol/media-type agnositic link relation
types for user authentication purposes.
https://tools.ietf.org/html/draft-pot-authentication-link
Nothing here is coupled to OAuth, but the lin
On 2019-02-22 10:29 a.m., George Fletcher wrote:
> I believe Torsten proposed an "authentication_failed" error response
> in a different context. Possibly we could use that?
>
> Alternatively, OpenID Connect defines a 'login_required' error that
> could work in this context as well. It doesn't fit
I read the Distributed OAuth draft, and I have a few comments and questions:
The draft defines 2 new link relations. "resource_uri" and
"oauth_server_metadata_uri". However, the underscore is actually invalid[1].
On the IANA Links Relations registry[2], most existing link relations
use dashes, or
org/arch/browse/oauth/?q=Distributed+OAuth&gbt=1&index=m1TUuh7Tcha9tuDrCraIrkjy73o
>
> So I guess to answer your question, there is interest in it and there
> is already some work in the form of a draft. Your input into
> developing that document would be welcomed.
>
&
ing on out-of-band knowledge of which authorization server
belongs to which client resource.
On 09/22/2018 03:54 PM, Phil Hunt wrote:
> Evert,
>
> See step “B” in sec 4.2 of RFC6749. The AS worries about authenticating the
> user.
>
> Phil
>
>> On Sep 22, 2018, at 1
Dear list,
Apologies if this has been brought up before. I searched the archives
but didn't find anything related.
I am working on a web application + api that uses OAuth2 implicit flow
and Bearer tokens.
It occurred to that when the API responds with a 401 request, a useful
addition would be tha
20 matches
Mail list logo
