I want to make a leptos example using this crate, but I'm a little confused on how best use it?

[sjud]

It looks like, I would run it alongside the server and then use the rauthy client to make calls to it? And it would act like google SSO acts but instead it is my own SSO. So if I deployed this next to my server, I'd basically be the SSO auth provider?
How best would I use this in a leptos example? Thanks for your work on this project!!

[sebadob]

It looks like, I would run it alongside the server and then use the rauthy client to make calls to it? And it would act like google SSO acts but instead it is my own SSO. So if I deployed this next to my server, I'd basically be the SSO auth provider?

correct

A leptos example, it depends if your leptos app is running with SSR or CSR. If it's SSR, then you could either do it like in one of the examples for the rauthy-client https://github.com/sebadob/rauthy/tree/main/rauthy-client/examples. It depends on your leptos setup of course, but for ease of use, you could just return the very minimal JS callback answer like in the examples. That's what I do in my apps as well, because the page is empty anyway. If you want to use leptos for the /callback as well and show some UI, you actually may need to expand your leptos setup a bit and handle the route requests for yourself. I am doing this too for all apps for different reasons. The main benefit is, that you can build up the context before actually rendering leptos itself.

As an example for an axum backend, you can do the following (since leptos v0.6 you don't need to specify the sever fn handler like in this screen shot any more):

Next, you can handle all the leptos routes yourself and have full control over it:

These example screenshots are taken from a small app I am working on right now, so they include more stuff than you would need (maybe).

You can take a peek at the client's cookies and HTTP header before even starting to render the leptos part. This way you can extract a session cookie or maybe an Authorization header beforehand, validate it, or redirect the user to a login, if he has no access to the requested route.

In the end, the whole thing would roughly look like that:

• Take a look at the client's access to a given route in the custom route handler via cookies, headers, ...
• If The client has a valid login, session, token, ..., just go on like normal. Otherwise, send an HTTP 301 and redirect to the login endpoint from Rauthy. This will be the /auth/v1/authroize with the proper values.
• Upon successful login with Rauthy, the user will be redirected to your callback URL, which you configure for the given client you are using in Rauthy. A minimal example how these could look can be found in the rauthy-client examples https://github.com/sebadob/rauthy/blob/main/rauthy-client/examples/actix-web/src/routes.rs.
• On the callback endpoint of your app, you will check the request and use the code from it to fetch the tokens for the user.
• At this point, it highly depends on your app, how you want to proceed. You could either go on with the user just using the access_token for authentication, or create a session. Both approaches have advantages and disadvantages of course.

Something else you could do is to take a look at leptos_oidc. I have never used it so far, because I use the rauthy-client everywhere, but this has been tested and is working with Rauthy as well. There are even examples.

If your app is using CSR, the whole thing would get a bit easier. Let me know if this is the case and I can give some guidance on that as well. I am just assuming you use leptos in SSR mode, which makes the most sense.

[sebadob]

Another much simpler approach to the one above, but of course with a different UX as well, would be to simply not use any custom routes extractor and return 301's from any protected endpoints, if the user is not logged in.
Meaning, if you access /protected from the leptos app and the user did not provide a valid token / session, simply return HTTP 301 and redirect to the login endpoint.
This would completely get rid of the custom routes handler, if you don't like the complexity. Then you only need to care about the callback endpoint. The rest will work as mentioned.

[sjud]

Incredible! Very informative and thorough. I'll be working on this in the next couple of weeks (hopefully) and will follow up here (if this is a good place to do so).
Thank you!

[sebadob]

if this is a good place to do so

If you are just asking for advice or something, starting a discussion would be cleaner. But if you have an issue, then this is the right place, yes.

So I guess this issue can be closed for now, since there just is none so far?

[erlend-sh]

Looks like you may as well move this from Issues to Discussion :) GitHub lets you do that.

[sebadob]

Thanks @erlend-sh . Didn't know github can do this. :)

[sjud]

Oh thanks! :)

[sebadob]

I got an E-Mail because of a post from you @sjud asking about upstream SSO providers, but I cannot see the post here.
Anyway, yes I am planning to support upstream auth providers. There is even an issue about it already #166 .

The title may not be totally clear, but when I will implement this issue, it will be a generic support for any upstream auth provider.

[sjud]

I got an E-Mail because of a post from you @sjud asking about upstream SSO providers, but I cannot see the post here. Anyway, yes I am planning to support upstream auth providers. There is even an issue about it already #166 .

The title may not be totally clear, but when I will implement this issue, it will be a generic support for any upstream auth provider.

Yes, I did post that. But then as I dug through the information available I found an answer to my question so I went and I deleted my question (I didn't want anyone to waste their time on it) little did I know you got an email about it. :)

Regarding a generic implementation, it seems like various popular SSO providers have slightly different processes which might make a fully generic implementation a pain. It might be beneficial for there to be some specific implementations for upstream auth providers, such the big five or six google, facebook, github, apple, microsoft, etc.

This would satisfy some aspiring rauthy users, providing their needed functionality for their onboarding process while also possibly laying the groundwork for a generic implementation later. Having a handful of specific implementations make the design of the generic much easier in my experience.

I've been reading the rauthy codebase, and I find it very accessible and I appreciate the way you've written it. You're responsiveness and willingness to share technical details is very inspiring and I'd like to contribute to the rauthy code base.

May I write a specific implementation for one such upstream auth provider and open a pull request for it? From there we can tweak details and I could hammer out all the popular ones and lay the groundwork for a future generic implementation. I'd love to get involved in this project! Please let me know what you think, thank you.

[sebadob]

I've been reading the rauthy codebase, and I find it very accessible and I appreciate the way you've written it. You're responsiveness and willingness to share technical details is very inspiring and I'd like to contribute to the rauthy code base.

Thanks a lot! :)

With generic I just mean, that any provider should work with the same setup and options.
I expect that all of them will work with auto-configuration anyway. Meaning, my idea is to only provide the issuer URL and Rauthy will do the lookup for the openid-configuration and do the rest.
To get some templates, the idea for now is to just have a dropdown in the Admin UI, which will fill the config inputs automatically.

If you just give me a few more days, I will lay down the groundwork for this feature. I already have an idea about it, how we can do this dynamically and support any amount of providers at the same time.

[sjud]

For sure! No rush. :)
Can I do some work on the documentation? I think I could be helpful there in presenting some of the concepts to users of rauthy. I think some people will want to use rauthy as a simpler alternative to keycloak and I think if I were to explain the concepts of realms and users, etc, and how to get the service up in running in a few typical self-hosted environments that would speed up early adoption. Also you should snag the domain name for rauthy
https://www.namecheap.com/domains/registration/results/?domain=rauthy
:)

[sebadob]

Oh yes, some book updates would be very nice.
The last new features are mostly missing in the book. Some update with screenshots would make things a lot easier for new users as well.
I also started creating a helm chart quite a while ago, but then I first implemented new features which would make the chart outdated again, so I postponed this. But now, we are almost there feature wise and not far from v 1.0.0. This will help new users a lot as well most probably.

The concept of realms in Keycloak is actually nice and mandatory for them, because they have the heavy weight JVM under the hood. If you need multiple realms with Rauthy, just depoly another instance, and you would get the maximum amount of flexibility and it does not really use that much additional resources anyway. That's why I did not even bother implementing something like this.

I already do have a few domain names. I am not sure yet, if rauthy will get its own or if it will be combined with a few other of my projects like Nioca (which I will bring forward as soon as Rauthy has the SSO upstream providers feature implemented). But yes, domains are not that expensive anyway, so why not. :) Makes sense for v1.0.0 at least at some point.

[sjud]

Oops I deleted another comment again. Sorry!

[sebadob]

Have you done any quantitative comparisons of rauthy vs keycloak/Ory with regards to memory footprint, start up times, req handling speed and through put? One problem with both of those services is that I expect their usage of garbage collected languages to give a "spiky" performance, Discord engineering blog explained that as their reason from moving away from Go to Rust for some back end services. Something like an authorization server which is so essential to the user experience should really be written in a low level langauge and I expect this project to get a lot of attention! :)
I'm finishing the leptos rauthy example and will use what I learn there to begin work on a new users guide. Thanks!

Not yet. This is one of the very last steps before v1.0.0 - benchmarks and performance tuning. There will not be too much to do, because I did a lot of this stuff already. The whole code base has been almost fully rewritten ~3.5 times by now, with quite a bit of optimizations.

Startup time of any Java application is not even worth mentioning when you have Rust or Go. The only thing that makes Rauthy start not as fast as it could are quality of life implementations, additional checks that a user cannot accidentially deploy a mismatching version (database version vs app version checks for instance) and such things.

Memory wise, Rauthy is, again, not as efficient as it could be, for a good reason.
Everything you need during normal login flows is actually cached almost for forever (12h by default). The cache is being updated preemptively when data is created or updated, which means it will already exist in the cache before the first GET comes in. Cache invalidation is handled manually for each entry as well. This means there is quite a bit of overhead to manage, but instead any data is just there in no time. The main reason why I did this a few years ago was to counter slow disk access (Raspberry Pi with SD cards for instance). Also, when you use a hosted Postgres which is a bit further away, you will not get into trouble with latency.

I have not done a single benchmark yet, but I expect Rauthy to be pretty good throughput wise, because

1. Rust + Axum is just super fast
2. Everything will be kept in a local cache copy all the time
   But the performance here will be really good for Ory as well, I guess (never used it). Keycloak is written in Java, but with Quarkus under the hood, its pretty fast as well. Actually, all of the examples will provide good enough speed for the real world. When you get into millions of users, things will start to make a difference. The big thing is behind the scenes. Java will simply need more resources and is more expensive to run in production than Go, and then Rust. If you throw enough resources at it, it will perform with (mostly) any user count.
   That is something that Rauthy still has a TODO for. The Admin UI users component uses client side pagination currently. This means at some point, the first fetch of the users will take longer than with smaller instances. As long as your dataset is small enough, I always prefer client side pagination, because the UI just feels that much more snappy. Rauthy will need some alternative component there which will be loaded if for instance user count will reach 50k (or whatever makes sense -> benchmarking TODO).

The spiky performance is true because of GC for sure, yes. But I don't think that you will notice it that much with an SSO provider, because you don't login that often than you write messages in discord for instance.

Its quite hard to compare metrics like these between applications, when they simply do different things under the hood.
But I am curious how Rauthy will perform when the first benchmarks are being done. There are a few TODOs in the code currently at places where I already know that they can be optimized, but optimization does not make any sense when you don't have benchmarks to verify them.