https://www.ory.sh/ logo
Join Slack
Powered by
Is it normal for the OIDC callback endpoint in kra...
# talk-kratos
m
Is it normal for the OIDC callback endpoint in kratos to redirect browser to its registration UI? That is, after a user successfully logins and consents to the scope on the external IdP login page
configuration:
Copy code
selfservice:
      default_browser_return_url: <https://ui.mydomain.com>
      flows:
        login:
          ui_url: <https://ui.mydomain.com/login>
        registration:
          ui_url: <https://ui.mydomain.com/registration>
          after:
            oidc:
              hooks:
                - hook: session
        settings:
          ui_url: <https://ui.mydomain.com/settings>
        error:
          ui_url: <https://ui.mydomain.com/error>
      methods:
        password:
          enabled: true
        oidc:
          enabled: true
          config:
            providers:
              - id: my-tenant
                provider: microsoft
                client_id: xxx
                client_secret: yyy
                microsoft_tenant: <http://mytenant.onmicrosoft.com|mytenant.onmicrosoft.com>
                mapper_url: file:///etc/config/oidc.microsoft.jsonnet
                scope:
                  - profile
                  - email
s
isn't the provider redirecting to the URL you configured with them?
m
It is.. which is 
kratos/self-service/methods/oidc/callback/my-name
but after redirect, kratos makes the browser redirect to registration page
So it’s like this: 1- POST kratos/self-service/login?flow=flow-id (responds 303) 2- Azure AD (user authenticates and responds 302) 3- GET kratos/self-service/methods/oidc/callback/my-tenant?code=value&state=value&session_state=value (responds 302) 4- the UI URL registered for registration (ui-app/registration?flow=new-flow-id)
s
Did you try to set the default browser return url in the after flow config?
m
yea, that’s set.. I wonder if this could be related to mapping claims to the schema.. if that fails (claims don’t fulfill required items in schema), would that cause this behavior?
s
Yes, but you should end up at the same flow id and see some details in the docs
m
That’s what it was actually.. so this was the OIDC mapper jsonnet I was using initially:
Copy code
local claims = {
        role: 'user'
      } + std.extVar('claims');

      {
        identity: {
          traits: {
            // Allowing unverified email addresses enables account
            // enumeration attacks, especially if the value is used for
            // e.g. verification or as a password login identifier.
            //
            // If connecting only to your organization (one tenant), claims.email is safe to use if you have not actively disabled e-mail verification during signup.
            //
            // The email might be empty if the account is not linked to an email address.
            // For a human readable identifier, consider using the "preferred_username" claim.
            [if "email" in claims then "email" else null]: claims.email,
            role: claims.role
          }
        }
      }
looking at the logs, I found out that since email is required in my schema and the email claim is missing in Azure AD’s response, the final json produced from that response is rejected
I had to change the mapper to look for 
preferred_username
claim instead
Copy code
local claims = {
        role: 'user'
      } + std.extVar('claims');

      {
        identity: {
          traits: {
            // Allowing unverified email addresses enables account
            // enumeration attacks, especially if the value is used for
            // e.g. verification or as a password login identifier.
            //
            // If connecting only to your organization (one tenant), claims.email is safe to use if you have not actively disabled e-mail verification during signup.
            //
            // The email might be empty if the account is not linked to an email address.
            // For a human readable identifier, consider using the "preferred_username" claim.
            [if "preferred_username" in claims then "email" else null]: claims.preferred_username,
            role: claims.role
          }
        }
      }
6 Views
Open in Slack
PreviousNext
Powered by