sebadob / rauthy Goto Github PK

The user needs to set their password after creating a new user account. Do we really need the e-mail field there? Because the e-mail is already known, otherwise the user couldn't click on the link in the mail. :D

A configurable template (outside form the source code, on runtime level) for the emails would be awesome! ❤️

Our backend would like to have the given_name, family_name and email, which aren't in the access_token. For that reason we would like to use the rauthy-client to fetch the userinfo from the /auth/v1/oidc/userinfo endpoint with the given bearer token. Does it make sense to implement something like that? The best approach would be an axum extractor, like the PrincipalOidc, which is doing the get request in the background.

The current flow is that a user can register an account, after register their account the user needs to verify there account. After clicking the verification/password reset the user gets redirected to the rauthy user dashboard/control center, which is a little bit confusing for the user. Speaken form a shop system it's disturbing that a user gets not back redirected to the shop and is "stuck in the rauthy dashboard". A configuration for a post_redirect_uri would be awesome! ❤️

The first authentication with [email protected] and the password provided in the logs works just fine with Firefox, but repeating the same procedure with Safari Rauthy responds with 401

Safari

curl 'http://localhost:8080/auth/v1/oidc/authorize' \
-X 'POST' \
-H 'Content-Type: application/json' \
-H 'Accept: application/json' \
-H 'Sec-Fetch-Site: same-origin' \
-H 'Accept-Encoding: gzip, deflate' \
-H 'Accept-Language: en-GB,en;q=0.9' \
-H 'Sec-Fetch-Mode: cors' \
-H 'Host: localhost:8080' \
-H 'Origin: http://localhost:8080' \
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.4.1 Safari/605.1.15' \
-H 'Content-Length: 335' \
-H 'Connection: keep-alive' \
-H 'Sec-Fetch-Dest: empty' \
-H 'Cookie: csrf_token_806060ca5bf70dff3caa0e5c860002aade9d470a5a4dce73bcfa7ba10778f481=Ek20e24SfsNU+94EfR6byle96p8amt7/Dy6YUGjk/I0=; csrftoken=v3fKCddmvGe3m4bwSON44pZ701LjvqyM; sessionid=cxphmdo2yu8k7j1z1ky0a1ungb2fs370; i_like_gitea=658bc76971b2a4d9; lang=en-US; intercom-device-id-a5br6kfe=a0718d23-68d1-435e-a316-37f289fbe632; intercom-id-a5br6kfe=c925cd6e-0168-4998-98a2-22a5291261c8; authentik_csrf=MPwZHl79DmyDzCcUyRjUudKnufcm4AYj; ph_phc_J9BPccikTHu60117bET17Qlz3v3asOF4H6L7b9XwHrS_posthog=%7B%22distinct_id%22%3A%22018d6dbb-7538-72ec-ae61-39575bc1a2fb%22%2C%22%24device_id%22%3A%22018d6dbb-7538-72ec-ae61-39575bc1a2fb%22%2C%22%24user_state%22%3A%22anonymous%22%2C%22%24session_recording_enabled_server_side%22%3Atrue%2C%22%24console_log_recording_enabled_server_side%22%3Atrue%2C%22%24session_recording_recorder_version_server_side%22%3A%22v2%22%2C%22%24session_recording_network_payload_capture%22%3A%7B%22capturePerformance%22%3Atrue%7D%2C%22%24autocapture_disabled_server_side%22%3Afalse%2C%22%24active_feature_flags%22%3A%5B%5D%2C%22%24enabled_feature_flags%22%3A%7B%7D%2C%22%24feature_flag_payloads%22%3A%7B%7D%2C%22%24sesid%22%3A%5B1707033873079%2C%22018d7323-2bbe-7f17-94c2-6f9876d40a69%22%2C1707033701310%5D%2C%22%24client_session_props%22%3A%7B%22sessionId%22%3A%22018d7323-2bbe-7f17-94c2-6f9876d40a69%22%2C%22props%22%3A%7B%22initialPathName%22%3A%22%2Frepositories%22%2C%22referringDomain%22%3A%22%24direct%22%7D%7D%7D; user_sess=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE3MDcxNDU4MDQsImlhdCI6MTcwNjk3MzAwNCwic3ViIjoic3Vra29sYSIsInR5cGUiOiJzZXNzIn0.FffCpBdwElXT9r3aDkw1wWE-NZSmuIU55PV4x-JjNvk; ph_phc_hnhlqe6D2Q4IcQNrFItaqdXJAxQ8RcHkPAFAp74pubv_posthog=%7B%22distinct_id%22%3A%22305923a9-d6a0-4951-9cae-4ce5d7e2d896%22%2C%22%24device_id%22%3A%22018c2ad4-2ce8-768e-9952-b8e7bbaf15ad%22%2C%22%24user_state%22%3A%22identified%22%2C%22%24sesid%22%3A%5B1701526517289%2C%22018c2ad4-2cea-7af5-a083-37f0901f6bb9%22%2C1701525597418%5D%2C%22%24client_session_props%22%3A%7B%22sessionId%22%3A%22018c2ad4-2cea-7af5-a083-37f0901f6bb9%22%2C%22props%22%3A%7B%22initialPathName%22%3A%22%2F%22%2C%22referringDomain%22%3A%22%24direct%22%7D%7D%2C%22%24session_recording_enabled_server_side%22%3Afalse%2C%22%24autocapture_disabled_server_side%22%3Afalse%2C%22%24active_feature_flags%22%3A%5B%22survey-targeting-product-fit%22%5D%2C%22%24enabled_feature_flags%22%3A%7B%22survey-targeting-welcome-to-netdata%22%3Afalse%2C%22survey-targeting-product-fit%22%3Atrue%2C%22user-age-less-than-7d%22%3Afalse%7D%2C%22%24feature_flag_payloads%22%3A%7B%7D%2C%22event_source%22%3A%22cloud%22%2C%22posthog_first_seen_at%22%3A%222023-12-02T13%3A59%3A57.909Z%22%2C%22posthog_first_distinct_id%22%3A%22018c2ad4-2ce8-768e-9952-b8e7bbaf15ad%22%2C%22%24user_id%22%3A%22305923a9-d6a0-4951-9cae-4ce5d7e2d896%22%2C%22%24stored_person_properties%22%3A%7B%22email%22%3A%22unknown%20email%22%2C%22name%22%3A%22%22%2C%22netdata_cloud_account_created_at%22%3A%22%22%2C%22netdata_cloud_account_created_days_ago%22%3Anull%2C%22spacesCount%22%3A1%2C%22maxNodesCount%22%3A0%7D%2C%22netdata_cloud_account_created_days_ago%22%3Anull%2C%22netdata_registry_person_guid%22%3A%22c76b4466-93a9-4716-bc0e-f23b6f0331e1%22%2C%22netdata_registry_machine_guid%22%3A%22b4ba753e-911a-11ee-9501-225b52356492%22%2C%22netdata_cloud_account_created_at%22%3A%22%22%2C%22netdata_cloud_account_email%22%3A%22unknown%20email%22%2C%22netdata_cloud_account_id%22%3A%22305923a9-d6a0-4951-9cae-4ce5d7e2d896%22%2C%22netdata_cloud_signed_in_at%22%3A%222023-12-02T13%3A59%3A57.909Z%22%2C%22%24flag_call_reported%22%3A%7B%22user-age-less-than-7d%22%3A%5B%22false%22%5D%7D%7D; _ga_J69Z2JCTFB=GS1.1.1701525597.1.1.1701526472.59.0.0; __hstc=181257784.ceb57c61916c5f08fbfb207aa1bc00bf.1701525597628.1701525597628.1701525597628.1; _ga=GA1.1.1681891015.1701525597; hubspotutk=ceb57c61916c5f08fbfb207aa1bc00bf' \
-H 'csrf-token: BTiODPFRFTklqCUXdYJB8FSl7q4Q5uim' \
--data-binary '{"email":"[email protected]","client_id":"rauthy","redirect_uri":"http://localhost:8080/auth/v1/oidc/callback","state":"account","code_challenge":"tA6X0WQ9PzRqwic2tdiES2uADnaLv7mzDpnUCwg7R3o","code_challenge_method":"S256","nonce":"2PjN5Y2HqwW7viDvEooYpg6j","scopes":["openid","profile","email"],"password":"3I930jYECCahJhzoD0xABTEI"}'

Firefox

curl 'http://localhost:8080/auth/v1/oidc/authorize' -X POST -H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:124.0) Gecko/20100101 Firefox/124.0' -H 'Accept: application/json' -H 'Accept-Language: en-US,en;q=0.5' -H 'Accept-Encoding: gzip, deflate, br' -H 'Content-Type: application/json' -H 'csrf-token: gCZkRkpuXQyzs9q8PnSHFWq891J6IbUS' -H 'Origin: http://localhost:8080' -H 'Connection: keep-alive' -H 'Cookie: rauthy-session=h42qJL3pNHTCoKpc6X7HDgRYbOiw43Cd; intercom-id-a5br6kfe=35a1417c-19b8-4387-9ccb-7e43654bee80; intercom-device-id-a5br6kfe=ca7fa307-bde6-4f50-9d76-2bb081a12728' -H 'Sec-Fetch-Dest: empty' -H 'Sec-Fetch-Mode: cors' -H 'Sec-Fetch-Site: same-origin' --data-raw '{"email":"[email protected]","client_id":"rauthy","redirect_uri":"http://localhost:8080/auth/v1/oidc/callback","state":"admin","code_challenge":"sgkSXnbFc9WLME7X_AlO4_YNyaB_hEP-zeAhaStc1WE","code_challenge_method":"S256","nonce":"jxoTUdTkfOxIi5rtdFS3ZeuP","scopes":["openid","profile","email"],"password":"3I930jYECCahJhzoD0xABTEI"}'

Logs do not provide additional information on why the check fails on the server side

Right now there is a encapsulated Register Screen and a encapsulated Login Screen, but both of them are not really "connected together", they are more or less standing on their own. For example, a User is getting redirected to the login screen of Rauthy, then remembers that he doesn't have an account, then he has no chance to create a new account. A small register button besides the login button would be awesome.

A second thing is, the user is more or less "stuck" on the login/register screen, if a user is on the login page and would like to cancel the transaction, he's completely stuck. There is no "go back" button, which would redirect the user to the source application. Of course he could use the "back function" of his browser, but the redirects are making it impossible and it's not really user friendly. ^^"

PS: I would like to help out and create a PR. The frontend and backend is running, but I have no idea how I can get test data into it. There is no rauthy client creation, no admin account, and I am a little bit stuck there. Would be awesome if someone could help me out, so I could create a PR. ❤️ Thanks!

Hi,

Do you think it may possible to add support of W3C DID and include DID-Web and if possible DID peer

Thank you,

RFC 2591 defines "OAuth 2.0 Dynamic Client Registration Protocol" (DCRM), which enables clients to register themselves directly at a standard endpoint.

It must be simple enough to create required endpoints, with just copying current client endpoints, and changing any auth details.

We can have the feature behind a config.

See also: OAuth 2.0 Dynamic Client Registration Management (DCRM) Protocol

I could make a PR, if feature is ok.

Following from this:

Keycloak was a rough inspiration in certain places and if something is working with Keycloak, it does with rauthy too (again, so far).

I wonder if rauthy might be interested in aiming for some baseline compatibility with https://github.com/matrix-org/matrix-authentication-service

https://matrix.org/blog/2023/09/better-auth/

The Matrix Authentication Service (MAS) lists Keycloak as a supported upstream Identity Provider (IdP). Since rauthy is ‘Keycloak conformant’ to some extent, maybe the path to interop with MAS is fairly clear-cut? Would be cool to have a pure Rust stack for that whole setup!

A user can reset their password and use characters like " in the reset (for example sj3478Dhksdk&jhB'\"6(4b7TB). After redirecting the user to the login page hes unable to login with with password. The server response with a

Validation errors in fields:
	password: Validation error: [a-zA-Z0-9,.:/_-&?=~#!$'()*+%]+$ [{"value": String("sj3478Dhksdk&jhB'\"6(4b7TB")}]

This should be allowed in the authorize endpoint or disallowed in the set password endpoint. :)

These contain

params(LogoutRequest),

in their utoipa definition which defines three path parameters that do not appear in the path, presumably this was meant to be a request body definition?

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!!

Since yesterday the version 0.21.1 and 0.22.1 is throwing a database error when I try to reset my password. ^^"

2024-04-22T09:23:14.856435Z ERROR rauthy_common::error_response: Database Error: ColumnDecode { index: "\"failed_login_attempts\"", source: "mismatched types; Rust type `core::option::Option<i64>` (as SQL type `INT8`) is not compatible with SQL type `INT4`" }

It's also throwing an internal server error on the /auth/v1/users endpoint (from the administrator perspective).
It's throwing the same database erorr, the client response is:

{
    "timestamp": 1713778066,
    "error": "Internal",
    "message": "Internal error, please try again"
}

Posgres version is 16.

Right now the GET /auth/v1/pow endpoint is only usable (with CORS) within the web ui. We would love to get a pow challenge without disabling CORS in the client. This would add the opportunity to create a custom frontend for user registration, just fetching a pow challenge, solve that challenge and create a POST /auth/v1/users/register for the registration. :)

Solution 1: Add a global ALLOW_ORIGIN config entry, which will be used for all that endpoints (GET /auth/v1/pow, POST /auth/v1/users/register).

Solution 2 (my personal preferred solution): Adding a client_id to the query could help to set the ALLOW_ORIGIN for the client. So this would mean that a pow challenge could be obtained by a GET /auth/v1/pow?client_id=test and their ALLOW_ORIGIN entry from that specific client.

Note: I am not sure about the POST /auth/v1/users/register endpoint, but I think the frontend would have the same issue there as well and would ran into some CORS issues (maybe adding a client there as well?). ^^"

It would be great if rauthy bootstrap could be automated with software like Terraform/OpenTofu, e.g. by passing the initial admin credentials (email, password, possibly an admin API token) as environment variables the way other software does for bootstrap.

That way installing and then configuring rauthy via something like a Terraform provider could be fully automated without any manual steps.

After register a new user, the user needs to verify their email. The verification email is the base template for resetting their password, which is a little bit confusing for the user. A seperate welcome email would be awesome! ❤️

Hey,
Wanted to ask what places you mean in particular /o\

I just found out that the Button labels are currently a bit out of place on chrome based browsers.
I did not notice that lately since I am using Firefox only, where they are centered.

On chrome based browsers, they seem to have a bit too much margin-top. Wherever this is coming from, it should be fixed.

Firefox:

Chromium:

Signing in with google, github , etc, through oidc will be highly convinient for many service instances.

• All the text inputs have autocomplete off. At least for debugging it's annoying to have to retype everything
• Indicate which fields are required. As an example, Providers>Add New>Submit hangs unless I specify both a Client Name and Client ID.

I developed obligator with many of the same design goals as Rauthy. Honestly if I had known about Rauthy at the time (it was brought to my attention recently by @erlend-sh) it might have met my needs better than making my own from scratch. Rauthy is much more complete. Anyway, I was wondering if you might help me fill out/fix any errors I may have made concerning Rauthy in the comparison table here. You can suggest edits to the source spreadsheet here. Thanks!

The possibility to filter by last login or account age in the admin user area would be very helpful.

Admin user area: https://example.com/auth/v1/admin/users

Currently auth/v1/ prefix is hardcoded into rauthy. Instead it would be valuble, if we take prefix from config instead.

Thus service owners can choose it to be no-prefix, (if they have scoped at subdomain level like auth.ex.org), or custom prefix like accounts/v1/ (as in google apis for eg.)

I will implement the RFC 8628: OAuth 2.0 Device Authorization Grant, formerly known as device flow.

This will make it possible to authenticate in places, where you don't have access to a browser.
For instance a CLI tool on a remote host via SSH or embedded / IoT devices.

This issue will be implemented with multiple PR's to keep them smaller and easier to review.

      +----------+                                +----------------+
      |          |>---(A)-- Client Identifier --->|                |
      |          |                                |                |
      |          |<---(B)-- Device Code,      ---<|                |
      |          |          User Code,            |                |
      |  Device  |          & Verification URI    |                |
      |  Client  |                                |                |
      |          |  [polling]                     |                |
      |          |>---(E)-- Device Code       --->|                |
      |          |          & Client Identifier   |                |
      |          |                                |  Authorization |
      |          |<---(F)-- Access Token      ---<|     Server     |
      +----------+   (& Optional Refresh Token)   |                |
            v                                     |                |
            :                                     |                |
           (C) User Code & Verification URI       |                |
            :                                     |                |
            v                                     |                |
      +----------+                                |                |
      | End User |                                |                |
      |    at    |<---(D)-- End user reviews  --->|                |
      |  Browser |          authorization request |                |
      +----------+                                +----------------+

Registering a user should redirect him after registration to the original request.

Steps to reproduce/explain:

1. When using the authorization_code flow, the client gets redirect to the /authorize page and shows the login screen.
2. On that page there is a User Registration button, which redirects the user to the registration page.
3. After filling up that page, the user gets a confirmation mail which needs to be fulfilled with a password (or FIDO2).
4. After settings the password, the user gets redirected to the base url of the rauthy instance (with the rauthy client in the url).
5. When the user is now logging in, the user gets stuck on that application/client.

It would be awesome if a user could register an account (after pressing the User Registration button) and would be redirected to the same origin he came from (in that case the client_uri). Is it possible to redirect the user to the redirect_uri, client_id, state where the user came from?

The problem here is that we have a shop system where we have just a single login button on that page. And After that the user can see a registration button on the login page (which is awesome, thanks to #308 ), but After register their account, the user is not on the shop anymore and has no way to find back (except typing in the url).

Thank you very much for your time! ❤️

I wanted to give this a try, but now I have to add a MFA provider for my local test instance.

Don't assume to know better than anyone and tell people how to use your their software.
Also, what's wrong with just admin@localhost, why does it have to be localhost.de ?
admin@localhost is a perfectly valid email address, even a@a is.

For me, this forced MFA is a reason to not use this software.

if i see it correct, everything is managed with the admin ui ...

If I go to ADD NEW AUTHENTICATION PROVIDER, select Google from the dropdown, then select OIDC, I still see the form for Google.

Is it currently possible to configure rauthy completely or partial via environment variables (e.g. docker compose)?

If not, what / where would changes need to be made?

Short-version: I suggest to drop /tokenInfo, and instead implement /introspect which appears to be missing support despite being the official OIDC endpoint for this purpose?

/tokenInfo

Presently there is a /tokenInfo endpoint:

When querying /.well-known/openid-configuration for the /introspect token introspection endpoint, it reports /tokenInfo endpoint instead:

{
  "introspection_endpoint":"http://localhost:8080/auth/v1/oidc/tokenInfo"
}

That endpoint however is not equivalent and appears to be non-standard / inconsistent across implementations? (note all the following references have deprecated this endpoint):

• https://auth0.com/docs/api/authentication#get-token-info
• https://help.salesforce.com/s/articleView?id=000927357&type=1
• https://www.microfocus.com/documentation/access-manager/developer-documentation-5.0/oauth-application-developer-guide/tokeninfo-endpoint-details.html (related: /introspect endpoint)
• https://backstage.forgerock.com/docs/am/7/oauth2-guide/legacy-oauth2-endpoints.html#varlist-oauth2-tokeninfo-endpoint (related: /introspect endpoint)
• https://developer.onewelcome.com/documentation/iwelcome-endpoint-details#token-info-on-tokeninfo-endpoint (notes support ceased by this service at the end of 2020)

I could not find any RFC where /tokeninfo is defined as a standardized endpoint (despite rauthy swagger docs implying it is OIDC standard?):

• This claims the endpoint is part of the OAuth2 spec, but no valid reference link.
• It appears likely that /tokeninfo is an endpoint defined by Google that became more widely adopted before better standardization landed? Similar to what Google had done with XOAUTH2 before OAUTHBEARER was standardized.

I did a brief search before raising this issue and found no context for why this was implemented. The endpoint was already present with your open-source release commit, so no context from that history either.

/introspect

Given the above, it should be communicated more clearly that this is a legacy endpoint, or potentially considering dropping it as I'm not sure what value it might provide for rauthy? If there is demand for it for some reason, I'm sure those users would engage here to clarify why.

Instead /tokenInfo should be replaced by /introspect endpoint, with the implementation conforming to RFC 7662 - Section 2 where this endpoint is defined.

References for the /introspect endpoint documented by alternative open-source services:

• https://www.ory.sh/docs/hydra/reference/api#tag/oAuth2/operation/introspectOAuth2Token (Ory Hydra differs from others with protected routes, delegating to the sysadmin to decide)
• https://zitadel.com/docs/apis/openidoauth/endpoints#introspection_endpoint (like most implementations, basic auth tied to client credentials, the RFC only requires the route to be protected but not how, some software like Dovecot expects basic auth support)

Feedback - OpenAPI docs

I realize any standardized APIs should probably avoid straying from case conventions, but I did find it a little odd to encounter some endpoints that used camelCase, and a little bit for those that used snake_case.

• kebab-case is most appropriate for these when you have the control to decide, so that might be a breaking change you'd want to consider phasing in at some point.
• For /tokenInfo I believe elsewhere it was most commonly /tokeninfo, although one resource did have /token-info. Mostly a non-issue given OIDC provides an endpoint to easily query these 👍

NOTE: It'd also be neat if the endpoints were documented publicly online instead of needing to run rauthy to lookup via swagger docs. I know we're all limited with time, so it's probably just wishful thinking 😄

If you're curious at all, the Ory Hydra OpenAPI docs are implemented via using Redoc instead of Swagger, and Docusaurus instead of mdBook for docs in general, to integrate those two together they've used Redocusaurus.

• Docusaurus does supports some more advanced features, but for the most part is markdown focused like most doc generators, so it shouldn't be too different if you were to consider migrating.
• I'm not sure why by both rauthy and kanidm docs on Github Pages seem rather slow to load when I would visit them each time, which isn't the case with Github Pages for docs generated with MkDocs Material (another which I have worked with).

Configuring upstream OIDC was very straight-forward. However, I noticed that one of my email addresses didn't work, resulting in

Uncovered HTTP return status '400'. This should never happen, please report this bug.

The email address contains a "&" character, which is valid in email addresses. My best guess is the validator didn't like that.

called `Result::unwrap()` on an `Err` value: error sending request for url (http://localhost:8080/auth/v1/.well-known/openid-configuration): http2 error: connection error detected: frame with invalid size

From main.

   rauthy_client::init(None, RauthyHttpsOnly::No, DangerAcceptInvalidCerts::Yes).await.unwrap();

    let config = RauthyConfig {
        // If this is Some(_), the principal will have a .is_admin field being set correctly, if
        // this claim matches.
        admin_claim: Some(JwtClaim {
            typ: JwtClaimTyp::Roles,
            value: "admin".to_string(),
        }),
        // This claim must always exist for every single user. Without this claim, a user would
        // not have access to this app. This is used, because usually you never want to just have
        // all your OIDC users to have access to a certain application.
        user_claim: JwtClaim {
            typ: JwtClaimTyp::Groups,
            value: "user".to_string(),
        },
        // In almost all cases, this should just match the `client_id`
        allowed_audiences: HashSet::from(["localdev".to_string()]),
        client_id: "localdev".to_string(),
        // If set to 'false', tokens with a non-verified email address will be rejected.
        email_verified: true,
        // The issuer URL from your Rauthy deployment
        iss: "http://localhost:8080/auth/v1/".to_string(),
        // The scopes you want to request. The only mandatory which always needs to exist is
        // `openid`, the rest is optional and depending on your needs.
        scope: vec![
            "openid".to_string(),
            //"email".to_string(),
            //"profile".to_string(),
            //"groups".to_string(),
        ],
        // If set to None, the client will be treated as a public client and not provide any
        // secret to the /token endpoint after the callback. Set a secret for confidential clients.
        secret: None,
        // secret: Some("secretCopiedFromTheRauthyUiIfIsConfidentialClient".to_string(),),
    };

     // The redirect_uri here must match the URI of this application, where we accept and handle
    // the callback after a successful login.
    OidcProvider::setup_from_config(config, "localhost:3000/redirect_uri").await.unwrap();

I don't think this is reproducible I think it's specific to my own development machine. But I'm not sure why.

Edit:

My server is getting

2024-02-18T19:45:01.904957Z ERROR actix_http::h1::dispatcher: stream error: request parse error: invalid HTTP version specified

So it looks like it is expecting a different http version?

It seems to be handling HTTP 1 just fine

2024-02-17T23:53:38.897744Z  INFO rauthy_handlers::middleware::logging: 172.17.0.1 HTTP/1.1 POST /auth/v1/scopes "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0"

Currently rauthy can be deployed as standalone application, but is not trivial to plug into an existing rust api, with custom configurations, mount point, etc.. as they all are globally dispersed and hardcoded.

If we can instantiate an RAuthy instance with custom config, and plug to actix application's scope, it will be highly embeddale into any kind of rust app.

If open to idea, i could work on that.

I can see a lot of events that some random/phishing IP addresses are getting blacklIst from rauthy (which is good), but none of them are shown in the blacklist tab. Is this intendeded? :)

In the admin users dashboard you can filter user in the search area. After deleting a user from that list, the filter resets. The string is still in the search area, but the filter is not applied. Remove or adding one character to the filter updates the list again. :)

Nothing import, minor ui improvement. :D

Hi 👋

I noticed that one of the less "critical" TODOS in the readme is

Maybe get a nicer Rauthy Logo

I'd like to help with that.

If there's already some ideas for what needs to be conveyed, can I get a general direction for the desired style / direction / concept and I can then provide a few options for and we can iterate / based on those until we reach a final version.

Anything from your end works for me, text-based description / rough lineal sketch / existing examples or inspirations are all ok. If there's strong preference for ideas or concepts that must be included (like a specific color palette) those would help too.

Alternatively, if there's no strong preference for the direction in general, I can also create a few prototypes and we can go from there.

After #259 I'm one step further to authenticate to Forgejo using rauthy.

Now I'm struggling with that error (Forgejo log):

2024/02/08 20:58:07 ...rs/web/auth/oauth.go:937:SignInOAuthCallback() [E] UserSignIn: userinfo 'sub' claim ([email protected]) did not match id_token 'sub' claim (MyUiDFromRauthy)

Is there a way to remap the sub field in the JWT to the E-Mail address of the user?

After looking in docs and checking with the API I am going to ask the question here?
How can I set the preferred_username to something other than the email?

I was successful in sending it as an attribute, but normal oidc clients do not accept attributes as a claim.

Am I just not seeing the setting?

Thanks for the great software!

I was evaluating Minio + Rauthy last week for a new project and found out, that this combination does not work anymore, even though it did in the past.
The problem is, that Minio is complaining about the OKP / ed25519 keys exposed in the jwks_uri. Rauthy can issue tokens with ed25519 and they are even the default, because they are the safest and most efficient option. Minio however does not recognize these and simply exits with an error, when it does a lookup to this URL, instead of ignoring the unknown JWKs.

There are 2 possible solutions for this:

1. I already opened an issue about it and I hope, that Minio will simply ignore unknown keys from this URL, which makes a lot of sense.
2. Introduce a new config variable to not show OKP keys in the jwks_uri on Rauthy's side. This would however affect other applications that already use these key types and therefore would not get these JWKs this way.

It depends on the outcome of the linked issue, how we will proceed with this.

I'm trying to configure Forgejo to log in with rauthy, but I can't get the "OpenID Connect Auto Discovery URL" to work. To my understanding, the URL would be:

https://id.example.com/.well-known/openid-configuration

id.example.com is the domain where rauthy is running and working properly so far, but /.well-known/openid-configuration returns a 404 not found.

Am I doing something wrong?

Hello, thanks a lot for rauthy. It really fills important void.

This is request to add support for RFC 9449 DPoP.

OAuth 2.0 Demonstrating Proof of Possession (DPoP) is a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens.

dpop is in development for many years, and proven to be defacto standard. Now it is also an official rfc. Keycloak also landed support for dpop recently. It also enables to have decentralized identities.

It would be great to have the support in rauthy.

Solid-OIDC spec mandates dpop. I am also the maintainer of Manas project that aims to create Solid protocol compliant servers. Storage part is done. solid-oidc compliant oidc provider is the next move to finally bring in complete solution. I am very hopeful on adapting rauthy for the purpose. Hope there can be collaboration.

Thanks again for great work.

The index page loads, but then when I click admin login. I get a 400 malformed request: Invalid redirect uri
The redirect url is well formed but in my browser console I get this error.

GET
http://localhost:8080/auth/v1/oidc/authorize?client_id=rauthy&redirect_uri=http://localhost:8080/auth/v1/oidc/callback&response_type=code&code_challenge=97GbYIUOZRKgJkrLaiyPL4FAyVv617A4IwyL0ueYO-M&code_challenge_method=S256&scope=openid+profile+email&nonce=2PDS7L1qt9jT7UDFq6JvWtIf&state=admin
[HTTP/1.1 400 Bad Request 1ms]

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

and I can source that to frontend/svelte.config.js:23

'script-src': ['self', 'wasm-unsafe-eval'],

I can't mess with this without breaking the entire app unfortunately.

Also, the docker image works perfectly. It's just when I try to run it from the just file on my local machine when I get issues.

Adding 'unsafe-inline' to line 23

'script-src': ['self', 'wasm-unsafe-eval', 'unsafe-inline'],

Causes this warning (and no fix)

  Content-Security-Policy: Ignoring “'unsafe-inline'” within script-src: nonce-source or hash-source specified

My guess is that it is coming from

frontend/src/routes/oidc/authorize/+page.svelte

Since the route I am trying to access unsucessfuly is http://localhost:8080/auth/v1/oidc

But also because frontend/src/routes/oidc/authorize/+page.svelte contains the word nonce
unfortunately this is the first time I've ever looked at a .svelte file so I'm not sure what I'm looking at exactly.

Edit 1:

Okay so it looks like we pull the nonce from the query in the url so the nonce is nonce=2PDS7L1qt9jT7UDFq6JvWtIf

But this only is set on_mount, and there is a flash before I get this error. So what happens before that? Could the error because by nonce being initiated to '' ?

I hardcode the nonce to

let nonce = 'jw1XcRxdnwXT08HbnCVB45Qr';

Not because this will fix anything, but can I cause a different error? Unfortunately, no same error.

I am getting this message "You need to enable javascript" in my response, although that isn't being displayed anywhere on the page just in the body of the response of the 400 get request that set this whole chain off.

I see that is from BrowserCheck on this login page, under a noscript header. I assume I am triggering it becaues the javascript is inline and apparently that's not being allowed?

What's interesting is that when I run the docker image. I actually get the same error

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

Except that it sucessfully redirects me to the email login page so I never noticed before!
Edit 2:

Okay, I think the url nonce and the nonce in the scripts are different. So what I'm going to do is this follow the csp guides and add nonces
https://kit.svelte.dev/docs/configuration#csp

Edit 3:

Even though the csp guide suggests this is done automatically in some capacity, I mass replace <script> with <script %sveltekit.nonce%> in every svelte file (but ignore, templates, html etc)

Nope, that does nothing.

I forgot to mention that I am also getting this error on the first time I click Admin login

XHR GET
http://localhost:8080/auth/v1/oidc/sessioninfo
[HTTP/1.1 401 Unauthorized 2ms]

Could that be something? I'm off to investigate!

Edit 4:
Okay so we probably don't have a session and are getting the unauthorized response from the handler.

Let's go back to the error message and try to answer some fundamental questions.

Content-Security-Policy: The page’s settings blocked the loading of a resource at inline (“script-src”).

The page's settings , well what are the page's settings?

content-security-policy | frame-ancestors 'none'; object-src 'none';

Hmm neither of those are relevant.

If I just disable the csp by deleting all of the directives I actually don't get the error in the console.but I still get the error displayed on the web page and the no javascript response. Hmmm.

Context:

Rauthy forces TLS connections right now. It tries "real" TLS first and will try again with a downgrade to STARTTLS, if this fails. It will never allow plaintext, because it should really never be used in a real deployment.

This works great and, indeed, real production / staging deployments should always be encrypted, but would it be possible to support plaintext only during development? The can be 100% tied to DEV_MODE to prevent any accidental configuration mishaps.

Use case:

Running Rauthy via docker compose with "throw away" containers and local SMTP via something like MailHog, or MailDev allows for a tighter feedback loop during development. This includes testing user registration flows / API key setups / magic links and data storage.

Expected result:

When DEV_MODE is set to true in Rauthy config, it should be possible to configure Rauthy to use local SMTP (even if non-encrypted)

Actual result:

Rauthy attempts to connect a few times and fails and then the container exits.

Following #263, the next issue I now see in the Forgejo log is:

2024/02/09 15:50:33 ...rs/web/auth/oauth.go:937:SignInOAuthCallback() [E] UserSignIn: Non-200 response from UserInfo: 404, WWW-Authenticate=

The configuration looks like this:

I checked the content of https://id.example.com/auth/v1/.well-known/openid-configuration: The field userinfo_endpoint points to https://id.example.com/auth/v1/oidc/userinfo. Manually curl-ing this endpoint gives:

{"timestamp":1707494056,"error":"BadRequest","message":"Authorization header missing"}

This is expected, as I'm not authenticated with curl.

Any idea what's wrong?

If you would go to the authorization at /auth/v1/oidc/authorize and make an error in the e.g. redirect_url like this:

http://localhost:8080/auth/v1/oidc/authorize?client_id=rauthy&redirect_uri=http1://localhost:8080/auth/v1/oidc/callback&response_type=code&code_challenge=919cZTslqlJKfD7-ncc5ivtfysYA_O3gy9DMV3Plvu0&code_challenge_method=S256&scope=openid+profile+email&nonce=7qLW7gcA4LhRhchuVL1dlEAM&state=admin

Then you are presented with just an empty page. It's happening because all of the <link> in the HTML page are addressing resources via ./_app/ (single dot) instead of the correct ../_app/ (double dot).

Would be awesome if this project would use leptos, this would help to get rid of the entire just/npm stuff. ❤️

Also one idea about leptos is, the frontend could be behind a feature flag and vice versa, headless feature would be awesome. :)

Feel free to close this issue, if you are not interested in leptos, or reach out if you need help! ❤️

The Rust rsa crate has been found vulnerable in some form to the Marvin Attack.
The maintainers are actively working on a fix for this in RSA/394 .

As soon as this fix is in place, Rauthy will be updated with the new version to mitigate this attack.
A change to something like boring will not be done, because I want to stay pure Rust as much as possible and the compilation to musl targets should not be broken (which would happen with C bindings like boring).

+ sed -i 's/lang="en"/lang="{{ lang }}"/g' templates/html/account.html
sed: 1: "templates/html/account. ...": undefined label 'emplates/html/account.html'
error: Recipe `build-ui` failed with exit code 1

It looks like the files were built
I can see a templates/html/account.html file but no replacement.

<!DOCTYPE html>
<html lang="en">
. . .

Encrypted SQLite backups will be one of the next features.
Additionally, it should be possible to automatically push them to a remote location like S3 storage.

Since I need this functionality in other projects as well, I started working on a whole new crate for that purpose.
It will be able to do this (and more) easily.

Once this new crate has reached its first stable state, I will use it to implement these features into Rauthy.

Steps to reproduce

Start a fresh instance of rauthy; v0.20
Image: ghcr.io/sebadob/rauthy:0.20.0-lite

/app/rauthy.cfg

SMTP_USERNAME=xxx
SMTP_PASSWORD="xxx"
SMTP_URL=xxx
SMTP_FROM="xxx"

ENC_KEYS="
yOMwXiAS/6VwWOIDfXCOHu9rDIgP9Rd3IWOoctuFoyGKeTcrkkEE=
"
ENC_KEY_ACTIVE=yOMwXiAS

EVENT_EMAIL="xxx"

Additionally, the following environment variables are set:

  -e 'DATABASE_URL'='sqlite:/data/rauthy.db' \
  -e 'EMAIL_SUB_PREFIX'='xxx' \
  -e 'LISTEN_PORT_HTTP'='36013' \
  -e 'LISTEN_SCHEME'='http' \
  -e 'PROXY_MODE'='true' \
  -e 'PUB_URL'='xxx' \
  -e 'SWAGGER_UI_INTERNAL'='false' \

Expected outcome

• Application starts up

Actual outcome

...
2024-01-12T09:00:43.629640Z  INFO rauthy: Starting secrets migration
2024-01-12T09:00:43.629675Z DEBUG sqlx::query: summary="SELECT * FROM events …" db.statement="\n\nSELECT\n  *\nFROM\n  events\nORDER BY\n  timestamp DESC\nLIMIT\n  $1\n" r
ows_affected=1 rows_returned=0 elapsed=51.841µs
2024-01-12T09:00:43.630242Z DEBUG sqlx::query: summary="PRAGMA journal_mode = WAL; …" db.statement="\n\nPRAGMA journal_mode = WAL;\nPRAGMA foreign_keys = ON;\nPRAGMA synch
ronous = NORMAL;\nPRAGMA auto_vacuum = INCREMENTAL;\n" rows_affected=0 rows_returned=1 elapsed=327.382µs
2024-01-12T09:00:43.630406Z DEBUG sqlx::query: summary="select * from clients" db.statement="" rows_affected=1 rows_returned=1 elapsed=68.19µs
2024-01-12T09:00:43.630487Z DEBUG sqlx::query: summary="select * from jwks" db.statement="" rows_affected=1 rows_returned=4 elapsed=42.791µs
2024-01-12T09:00:43.630511Z ERROR rauthy_common::error_response: aead::Error
2024-01-12T09:00:43.630526Z DEBUG rauthy_models::events::ip_blacklist_handler: Running IpBlacklistReq::CheckExp
2024-01-12T09:00:43.630537Z DEBUG rauthy_models::events::ip_blacklist_handler: Removing 0 IPs in IpBlacklistReq::CheckExp
2024-01-12T09:00:43.630540Z DEBUG rauthy_models::events::ip_blacklist_handler: IpBlacklist ExpChecker has been stopped
thread 'main' panicked at rauthy-main/src/main.rs:303:10:
TEMP_migrate_to_cryptr to succeed: ErrorResponse { timestamp: 1705050043, error: Internal, message: "Internal Encryption Error" }
stack backtrace:
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.