Hello Daniel!
Some time ago I started an open source project: Loginbuddy.
Loginbuddy is a tool that mainly supports OpenID Connect based logins.
It can be deployed as a standalone service or be used as a side-car next to
other docker containers in the same network.
Although it is not necessarily
hich I feel like might be a stretch to say that's typical, but
> this scenario was clearly thought of ahead of time. Doing that would enable
> an AS to avoid storing server-side state.
>
> On Wed, Oct 13, 2021 at 1:50 PM Sascha Preibisch <
> saschapreibi...@gmail.com>
If the challenge is based on distributed authorization server
configurations, how would they handle PKCE? I imagine that managing the
state for PKCE is not less challenging than managing authorization codes on
the server side, preventing reuse of them.
With that in mind I am not sure if I follow th
Yeah, Daniel,
I remember we spoke about it. I do think my version is slightly different
as there is no access_token issued by the server.
Regards,
Sascha
On Wed, 29 Sept 2021 at 08:42, Daniel Fett wrote:
> That very much sounds like a static string as the access token plus DPoP.
>
> -Daniel
>
Vittorio,
I wrote an approach where a client would receive a grant by the
authorization server but issues the token itself. The post can be found
here:
https://oauth.blog/oauthblog.jsp (fancy name: Serverless Token Issuance) I
presented the idea at IIW right before I wrote the post.
I believe tha
ent vs client making
> the request. The former distinction doesn't really matter in this case,
> whereas in the latter distinction the client option seems to be breaking
> the spec (only the user agent should send it).
>
> Amichai
> On 5/26/21 4:15 AM, Sascha Preibisch wrote:
>
as well as e.g. 4.2.1, it seems
> pretty explicit that it's the user agent that makes the actual HTTP request
> (Authorization Request with all its params etc), after being redirected to
> it from the client, no? I don't see much wiggle room there to allow for the
> client to
Hello Amichai!
There could be several reasons why you see that behaviour in your web
browser. For example:
- This RFC suggests sending a request to the authorization server, get a
session specific URL back which can be forwarded to the authorization
server via the browser. This is OAuth PAR (Push
Hello Hannes!
I have implemented PAR a while ago in my open source project "Loginbuddy"
as documented here:
- documentation:
https://github.com/SaschaZeGerman/loginbuddy/wiki/Protocols-and-APIs
- endpoint: /pauthorize
I hope it hope,
Sascha
On Wed, 24 Mar 2021 at 12:54, Hannes Tschofenig
wrote:
menters-note-about-jar-fff4cbd158fe
>
> Best Regards,
> Taka
>
> On Thu, Nov 5, 2020 at 11:33 AM Sascha Preibisch <
> saschapreibi...@gmail.com> wrote:
>
>> Hi all!
>>
>> A while ago I implemented draft 00 of this spec:
>> - https://tools.ietf.org/
Hi all!
A while ago I implemented draft 00 of this spec:
- https://tools.ietf.org/html/draft-ietf-oauth-par-04
Now, in draft 04, I see that a request to the /authorize endpoint is
defined with client_id and request_uri. The client_id was added since draft
00 (see: https://tools.ietf.org/html/draf
In the past, customers brought to our attention that some clients were not
able to receive a new refresh_token and use it right away. For that use
case we added a different type of rotation. The new refresh_token was
exactly the same as the given one. Except that it had a new expiration
date, lifet
+1
On Thu, 16 Jul 2020 at 23:57, Vladimir Dzhuvinov
wrote:
>
> +1
>
> Vladimir
>
> On 15/07/2020 20:54, Dick Hardt wrote:
>
> +1
>
> On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef
> wrote:
>>
>> All,
>>
>> This is a call for adoption for the following OAuth 2.1 document as a WG
>> documen
+1
On Wed, 15 Jul 2020 at 13:40, Hans Zandbelt wrote:
>
> +1
>
> Hans.
>
> On Wed, Jul 15, 2020 at 7:43 PM Rifaat Shekh-Yusef
> wrote:
>>
>> All,
>>
>> This is a call for adoption for the following OAuth 2.1 document as a WG
>> document:
>> https://www.ietf.org/id/draft-parecki-oauth-v2-1-03.h
by the WG?
>
> ᐧ
>
> On Tue, Jul 7, 2020 at 4:04 PM Sascha Preibisch
> wrote:
>
>> Hi all!
>>
>> Here is the rest of my feedback. At the end I also included a list of
>> typos and the summary of changes that I have found between RFC 6739
>> and the
Hi all!
Here is the rest of my feedback. At the end I also included a list of
typos and the summary of changes that I have found between RFC 6739
and the current draft.
Regards,
Sascha
Section 2.3. Client Authentication
-
Draft and current:
- both documents contain this
Hi all!
I am reading through this document for the first time. I am mainly
looking at it in comparison to OAuth 2.0 (RFC 6749) and with the eyes
of a developer. I am trying to understand where phrases have changed
and, of course, where features are changing.
What is the best way to provide feedba
The document is called "...Best Current Practice ..." and includes
recommendations. Could it be sufficient to say "Authorization servers
support PKCE" in section 2.1.1? I believe MUST and other such terms
may not necessarily belong into such document.
Regards,
Sascha
On Wed, 6 May 2020 at 14:04,
+1
On Mon, 27 Apr 2020 at 01:42, Filip Skokan wrote:
>
> I believe implementers should be free to devise their own URIs and not be
> locked down to one by the spec, at the same time, and RFC6755 subnamespace
> would be good for guidance.
>
> So, I would suggest it be RECOMMENDED to use e.g.
>
I am also in favour of such metadata.
I just implemented the draft and I used a client, which had multiple
redirect_uris, for testing purposes. That in mind, one of my thoughts
is that it could also be an advantage to not only bind a client to use
PAR but in combination with a specific redirect_ur
I will be there if it is not getting worse. But in any case I am in
Vancouver.
Regards,
Sascha
On Mon., Mar. 9, 2020, 11:35 Daniel Fett, wrote:
> Hi all,
>
> can we do a quick roll call on who is coming or not coming to Vancouver?
>
> For me, at the current point in time, it depends on whether
Hi all!
I am reading through the latest draft ( ... dpop-02). When I got to
the first example request (bullet 5.) I saw that only 'grant_type,
code, redirect_uri' are used.
If I am not mistaken the recommendation is to generally use PKCE with
an authorization_code flow. Therefore, I wondered if t
hmOID":"2.16.840.1.101.3.4.2.1"
> },
> "payment":{
> "type":"sepa-credit-transfer",
> "instructedAmount":{
> "currency":"EUR",
> "amount":"123.50"
>
um 22:06 Uhr schrieb Torsten Lodderstedt
:
>
> Hi Sascha,
>
> > Am 22.04.2019 um 20:34 schrieb Sascha Preibisch :
> >
> > Thank you for the article, Torsten!
>
> my pleasure :-)
>
> >
> > I like that 'scope' is out of the game for these kinds of
Thank you for the article, Torsten!
I like that 'scope' is out of the game for these kinds of authorizations.
What I can see for the general use case is a required identifier
within the 'structures_scope' document that identifies the profile it
should be used for.
Thank you,
Sascha
Am Sa., 20.
horization server cannot set an appropriate value if it was not
passed in as a request parameter.
Thanks,
Sascha
Am Sa., 13. Apr. 2019 um 09:29 Uhr schrieb Schanzenbach, Martin
:
>
>
>
> > On 10. Apr 2019, at 19:39, Sascha Preibisch
> > wrote:
> >
> > I am late in t
I am late in the game, but not too late I hope.
I would like to see 'aud' be the requesting client_id. For identifying the
the target resource, a 'resource' claim should be introduced. I am also
suggesting to not introduce 'typ: at+jwt'. It is simply a jwt and the
validation process will show if i
27 matches
Mail list logo
