> On Mar 1, 2022, at 10:18 AM, Daniel Fett wrote:
>
> * The core of OAuth is easy to implement. The need to create or use a
> library might not be obvious to developers. Of course, if you want a proper
> implementation with correct error handling, observing all the security
>
>
> I like the idea of a machine-readable feature support document...
> discovering those documents might still be a problem, though.
Yay! I don't think it is hard to build a bot to iterate github/github and
pull these. It gives us a starting point for how to attack this problem.
The key
Hi Warren,
Am 02.03.22 um 17:05 schrieb Warren Parad:
I don't think flooding this thread with random libraries is going to
benefit anyone, so let's not do that.
I agree, and that was not the aim of my question.
Back to the question, and it is an interesting one. It makes sense to
dissect
Hi Daniel
I do think it’s a problem that’s worth addressing somehow.
I think there’s another factor, which is that the providers of OAuth2
Authorization Servers (where they don’t have their own SDKs specific to their
server) tend to lead the developer through how to do a “from scratch”
I don't think flooding this thread with random libraries is going to
benefit anyone, so let's not do that.
Back to the question, and it is an interesting one. It makes sense to
dissect it a bit first. Who is struggling with "OAuth libraries" and what
is even the responsibility of one of them.
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
**
*Hi all,*
*
While helping clients to onboard into the yes ecosystem, in my
consulting work, and in discussions with developers implementing OAuth
2.0, one topic comes up increasingly often: The (somewhat frustrating)
lack of good, modern, and universal OAuth libraries.
Many of the
