Gwojda / keycloakopenid

keycloakopenid
40 stars 16 forks source link

code is missing, redirect to keycloak #24

Open MarkKlerkx opened 10 months ago

MarkKlerkx commented 10 months ago

Hello,

I have problems redirecting to my website after authentication with Keycloak.

In thtraefik loggings I saw this error: {"level":"debug","module":"github.com/Gwojda/keycloakopenid","msg":"code is missing, redirect to keycloak","plugin":"plugin-keycloakopenid","time":"2024-01-14T10:30:40+01:00"}

In the Keycloak events I saw this event: CODE_TO_TOKEN_ERROR With the error: invalid_code

But I have no clue where I am doing anything wrong. Do you have any idea?

Thank you in advance!

Mark

Gwojda commented 10 months ago

Hey, Just released a new version with tags v0.1.35 Can u check the new feature and see if its ok now?

MarkKlerkx commented 10 months ago

Hello,

There error is fixed.

Thanks,

Mark

From: Gwojda @.> Sent: maandag 22 januari 2024 18:17 To: Gwojda/keycloakopenid @.> Cc: Mark Klerkx @.>; Author @.> Subject: Re: [Gwojda/keycloakopenid] code is missing, redirect to keycloak (Issue #24)

Hey, Just released a new version with tags v0.1.35 Can u check the new feature and see if its ok now?

— Reply to this email directly, view it on GitHubhttps://github.com/Gwojda/keycloakopenid/issues/24#issuecomment-1904455183, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGXWLVNC2VMBFLHF4ANJBSLYP2NIRAVCNFSM6AAAAABBZ7AHMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBUGQ2TKMJYGM. You are receiving this because you authored the thread.Message ID: @.**@.>>

MarkKlerkx commented 10 months ago

Hello,

I noticed one other thing: In the previous situation (with Traefik ForwardAuth) in the cookie the value for userEmail was the real email address. Now it is just the loginname.

Is it possible that this is also a bug in the plugin?

Thank you in advance!

Mark

@.***

From: Gwojda @.> Sent: maandag 22 januari 2024 18:17 To: Gwojda/keycloakopenid @.> Cc: Mark Klerkx @.>; Author @.> Subject: Re: [Gwojda/keycloakopenid] code is missing, redirect to keycloak (Issue #24)

Hey, Just released a new version with tags v0.1.35 Can u check the new feature and see if its ok now?

— Reply to this email directly, view it on GitHubhttps://github.com/Gwojda/keycloakopenid/issues/24#issuecomment-1904455183, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGXWLVNC2VMBFLHF4ANJBSLYP2NIRAVCNFSM6AAAAABBZ7AHMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBUGQ2TKMJYGM. You are receiving this because you authored the thread.Message ID: @.**@.>>

MarkKlerkx commented 9 months ago

Hello,

I think it is something with the scope option. But it is not clear to me how the real string should look like. So I tried several formats based on the example. But the plugin will not start with my tries.

Example: Scope: "<Scope [space deliminated] (default: 'openid', example: 'openid profile email')"

My tries: Scope: "(default: 'openid profile email')" Scope: "('openid profile email')" Scope: "openid profile email"

Edit: It was the last option (Scope: "openid profile email") but I used the wrong yml editor. So after I edit the yml file in Visual Code, the plugin starts to work back again.

But in the cookies, still the parameter "userEmail" only has the username as its value.

Fmowers commented 9 months ago

@MarkKlerkx I am not really sure what you are talking about when you say "in the cookie the parameter "userEmail" only has the username as its value." This plugin doesnt set an email inside a cookie. It sets potentially two different cookies. The regular cookie named Authorization with the bearer heading before the token and a user defined cookie name with a default name of AUTH_TOKEN containing just the token. What you are describing sounds a lot like the forward_auth middleware that is part of the traefik official middlewares. This is a middleware plugin that you use instead of the forward_auth middleware. Or in my case I use them both but in different situations on different ingresses. But if you are talking about the cookie named _forward_auth that look something like this COOKIE: _forward_auth = signature|expiration|email then you might be trying to use both middlewares at the same time and it is causing a conflict. Instead just use one auth middleware at a time. You might have to remove the forward_auth as a default middleware on the entire websecure entrypoint and define which middleware you want to use on each individual ingress like I do. But I assure you that I use both this middleware and the forward auth middleware on the same cluster just never the same ingress and each works fine on their own.

Fmowers commented 9 months ago

@MarkKlerkx If you are talking about the X-Forwarded-User header. That is a differnet issue and one I think we can fix. The default value for UserClaimName is preferred_username which could be a number of different things depending on how you configure keycloak. But if you set it to email then it should show your email. Or you can configure keycloak to have email as each user's preferred_username.

MarkKlerkx commented 9 months ago

Thank you for your reply! I did some research and I think my problem can be solved with the UserHeaderName. This is in my keycloakopenid config: Scope: "openid groups email profile" UseAuthHeader: "true" UserHeaderName: "X-Forwarded-User"

In Keycloak I added a mapper UserID (to add the sub / ID) in the cookie) and a userEmail mapper to add the email address in the cookie. But when I go to my website both were not present (see screenshots).

Do you have any idea what I am doing wrong?

keycloak 001 keycloak 003

keycloak 002

Fmowers commented 9 months ago

@MarkKlerkx The mapper doesnt add them to a cookie. It adds them to the token. This plugin adds the entire token to a cookie. Shown, in your picture, above this is the AUTH_TOKEN and the Authorization cookies. If you want to see the userEmail and userName values then you need to copy the AUTH_TOKEN and paste it into a jwt decoder to see what it contains. Alternatively, you can verify those values in the token by going to the Client Scope tab next to the Mappers tab shown in the first picture above. From the Client Scope tab there should be a sub tab called Evaluate (go there). From the Evaluate tab select the User you want to test from the drop down that appears once you start typing the user. After selecting a User you can then go below and use the side panel to select which token you want to evaluate. For example, Generated access token is one of the options in the side panel. It will generate and show you the decoded access_token that gets created for that user.

Screenshot 2024-03-06 at 4 49 06 PM

The UserHeaderName if set to userEmail will add the value of preferred_username from the access_token to a Header called userEmail. Which you can find in the browser's dev tools inside the Network tab by recording/tracing the requests. After navigating to the web app while tracing the network. You will find the Header located in the requests containing your web app's domain

Fmowers commented 9 months ago

@MarkKlerkx I created two examples to show you how the preferred_username can potentially impact your value for UserHeaderName: userEmail

Screenshot 2024-03-06 at 5 11 43 PM Screenshot 2024-03-06 at 5 11 19 PM

In the example above the username and email are not the same value and so the value for preferred_username in the generated token is just test

Screenshot 2024-03-06 at 5 12 06 PM Screenshot 2024-03-06 at 5 18 04 PM

In this example the username and email are the same so the preferred_username has a generated value of test@yourdomain.com.

If you dont want to use preferred_username as the value for UserHeaderName: userEmail then you need to use UserClaimName by changing the value from its default UserClaimName: preferred_username to UserClaimName: email