Clarify logout routes, nginx configurations and terms in documentation (an General Doc issues)

[ksaadDE]

Dear fellows,

I had trouble finding the right logout route that is needed for outline as parameter OIDC_LOGOUT_URI neither proposed proxy-auth-domain.foo.tld/akprox/sign_out (see #1113 (comment)) nor End Session | /application/o/<application slug>/end-session/ works (see https://docs.goauthentik.io/docs/providers/oauth2/). #2023 (comment) mentions the route /outpost.goauthentik.io/sign_out . All routes return 404 not found.

What works (for outline!) is OIDC_LOGOUT_URI=https://authentik.domain.tld/flows/-/default/invalidation/ but I think it invalidates the whole session on all apps. Not sure about this tho, it's not documented. There is discussion about that in #2023, however the outcome remains unclear.

Furthermore I tried to find out what "application slugs" are, but the documentation describes nothing except the fact that they exist!

My question and central point: Can we somehow clarify the terms and URLs? People should not waste time on that, especially because it is so essential.

I understand it is very hard to keep up the good work in the Software Dev Life Cycle and it is not easy to document properly, when you are with your mind within the inner-circle of the project. For us users, whether it is free or premium, we need the clarification on that.

I think we all are eager to help. Thank you in advance, lets discuss that!

[ksaadDE]

I tried to find issues related to this (might be more!):

• Proxy provider - Forward-auth (domain level) - how to logout? #1113
• Logging out from authentik should invalidate sessions of proxied applications #2023
• Sign out proxy app and then automatically the same with authentik  #3471

[rouke-broersma]

I use /end-session/ in my configurations and this works fine. I get redirected to Authentik when logging out in a connected application, and can then choose to log back in, log out of the specific application session or log out of Authentik completely.

Application slugs are the slug for the application you configured on the.. application. The field is literally called slug.

If you wish to find the correct url to use, go to the provider registered for the application. All valid uri's are listed on the overview page of the provider. Including logout url. There is no need to try to construct the url's manually based on a template you find in the docs. The provider overview simply lists whatever url's are valid for that provider.

[ksaadDE]

Thanks! So it's the /application/o/appname/end-session/ URL ? in the admin interface on route /if/admin/#/core/providers/ /E: leading to /if/session-end/appname/

The problem without the full invalidation of the Authentik session simply accessing the app again logs the user back in. So I will probably stick with a full session termination.

Application slugs are the slug for the application you configured on the.. application. The field is literally called slug.

Yes that's what I have found out as well, but what is a slug in this context? A field that is named like that does not say what the field does or where I can find it in the UI.

[rouke-broersma]

Thanks! So it's the /application/o/appname/end-session/ URL ? in the admin interface on route /if/admin/#/core/providers/ /E: leading to /if/session-end/appname/

/application/o/<app slug>/end-session/ but yes.

A slug in web context is a part of the url for a specific item such as the name of the provider/application. See: https://support.squarespace.com/hc/en-us/articles/205814578-URL-slugs

When you create the app, you give the app a slug. This is by default the app name but you can customize this as you wish. There's also a helptext available next to the slug field that specifies "slug: Internal application name use in URLs."

[ksaadDE]

Thank you. That makes sense!

Mozilla's Dev site describes it as:

A Slug is the unique identifying part of a web address, typically at the end of the URL. In the context of MDN, it is the portion of the URL following "/docs/".
https://developer.mozilla.org/en-US/docs/Glossary/Slug

Seemingly it's very prevalent in the NodeJS Community and in the News field as SEO optimization. I never heard of slugs before, only route (in all frameworks and apps). Ofc I've worked with key tags or titles in URL as well before. But I have never seen it called as a slug.

When you create the app, you give the app a slug. This is by default the app name but you can customize this as you wish.

Yes makes sense, I just tried to find the definition of Slug in the docs, but yea it was just a field in a request, nothing more. 👍 So the connect to the app name (or wtv is set up) was missing.

Maybe it's better to call it id, if it's just another (unique; albeit modifiable) identifier.

[rouke-broersma]

It should probably just be derived from the app name and/or accept the client ID tbh instead of being a user serviceable field.

[rwjack]

I'm not getting the whole discussion from the linked issue.

Is it, or is it not possible to do the following?

1. Log in to Authentik
2. Open app 1 (logs me in automatically)
3. Open app 2 (logs me in automatically)
4. Log out of authentik
5. Now I am logged out of both app 1 and 2

[rouke-broersma]

what?

OIDC logout routes. https://openid.net/specs/openid-connect-backchannel-1_0.html#Validation

This specification defines a logout mechanism that uses direct back-channel communication between the OP and RPs being logged out; this differs from front-channel logout mechanisms, which communicate logout requests from the OP to RPs via the User Agent.

If you read in my initial post, there's a central logout route to invalidate across all apps where the current user is loggedin e.g. OIDC_LOGOUT_URI=https://authentik.domain.tld/flows/-/default/invalidation/ and for a single app it is /if/session-end/appname/ (app slug = appname)

This invalidates your Authentik session, but not whatever session you've received from the apps you logged in to, so only potentially logs you out from the app you started the logout flow from. You will have valid sessions for all other apps until those apps sessions expire. This is because Authentik is missing back channel logout. The logout call is not forwarded to connected apps (as in the actual application, not the app in Authentik) and a lot of apps give out long lasting session tokens and then don't check back with the oidc provider whether or not the session should still be valid.

[rwjack]

yes exactly, so I think this is already in the oidc protocol, so it's just Authentik that's lacking the ability to:

• When logged out of Authentik
• Authentik calls the logout url on every connected application, ensuring sure the user is fully signed out.

[ksaadDE]

@rouke-broersma i did not try a session grab on the sessions provided by any app. But when I am doing the global logout route I can not login into any of the apps anymore, I would have to do the whole relogin flow. However, if you do the single app logout, you are still logged in to Authentik, thus you will be able to do sso on the apps by clicking sign in with the already logged in Authentik user. If that makes sense.

Not sure if Authentik lacks the backchannel logout feature but might be true. However, most apps request Authentik to verify the session request via OIDC, so it should not be a problem, as the sessions are only valid within Authentik's session validity.

Not sure what happens when Authentik (can it do so?) requests a session from an app and so on. I would say with caution: I did not try that. I am configuring the Apps to use Authentik via OIDC and the rest is upon Authentik, as far as I can see.

If the sessions by the apps are still valid, Authentik would not by compliant with Authentication requirements by all the IT-Sec and privacy legislation (laws).

[rouke-broersma]

However, if you do the single app logout, you are still logged in to Authentik, thus you will be able to do sso on the apps by clicking sign in with the already logged in Authentik user. If that makes sense.

Sure, this is the most common scenario imo. Logging out of one app where you connected through SSO usually does not log you out from the SSO provider nor other apps where you are logged in through that SSO provider. Unless you choose global logout of course.

However, most apps request Authentik to verify the session request via OIDC, so it should not be a problem, as the sessions are only valid within Authentik's session validity.
If the sessions by the apps are still valid, Authentik would not by compliant with Authentication requirements by all the IT-Sec and privacy legislation (laws).

That is simply not true, this is not a requirement of the authentication protocol and not something Authentik can enforce. It is up to the service provider (app) to timely validate if a token is still valid by contacting Authentik. This is often not done properly by apps, or is done through back/front channel logout. See for example: https://community.auth0.com/t/invalidating-an-access-token-after-user-logout/101398

Authentik cannot force the service provider to properly validate that the JWT is still valid, this is not on Authentik. On top of that many apps give out their own JWT with it's own validity etc on top of the Authentik token, and then don't properly check that the Authentik token is still valid, but rather only check their own token.

All this to say that it heavily depends on the apps you're using which scenario works and which doesn't.

[ksaadDE]

@rouke-broersma legally it is required under terms like "proper Authentication" to be law compliant, as Authentik acts as credential and session manager in that sense (if Authentik handles it)

his is not a requirement of the authentication protocol and not something Authentik can enforce

I linked the specs that define it's required in OIDC

In case the App (or "Service Provider") does not handle it correctly, obviously the App is responsible to do so. But that's a different scenario, if I see it right, just another aspect of the protocols.

many apps give out their own JWT with it's own validity etc on top of the Authentik token

While being another scenario, yes, that would be the App’s responsibility (their devs)

heavily depends on the apps you're using which scenario works and which doesn't.

I absolutely agree, this was partially my point but I see that it was not that clear 👍
However, in the scenarios where I use Authentic it does what I want it to do.

[ksaadDE]

Another example for the doc issues:
#13173

[ksaadDE]

There is also a lot of confusion regarding service-to-serivce / m2m token grabbing via client_credentials grant on API endpoint application/o/token.

e.g. #5860

[ksaadDE]

Authentik and Nextcloud OpenID/OAuth2

Those who want to use Nextcloud with Authentik beware, it requires a bit of more configuration than presented under https://docs.goauthentik.io/integrations/services/nextcloud/

Configuration in Authentik

You need a Provider, a Application, the average OpenID config, and so on.

The groups configuration is kinda special, which can be set in the Directory for each User. You need a Property Mapper for Nextcloud assigning it after a user’s login. Beware that Nextcloud uses the "admin" group to provision admin permissions (access to the Nextcloud admin panel).

For example, I have added a nc_admin Group in the Authentik Directory, which allows me to set Nextcloud Admins in Authentik. However, usually this would create a new group (in Nextcloud), thus we drop the group from the groups array, and instead add "admin" with in the Property Mapper:

## Extract all groups the user is a member of
groups = [group.name for group in user.ak_groups.all()]

# Nextcloud admins must be members of a group called "admin".
# This is static and cannot be changed.
# We append a fictional "admin" group to the user's groups if they are an admin in authentik.
# This group would only be visible in Nextcloud and does not exist in authentik.
if user.is_superuser and "admin" not in groups or "nc_admin" in groups:
  if "nc_admin" in groups:
    groups.remove("nc_admin")  
  groups.append("admin")

return {
    "name": request.user.name,
    "groups": groups,
    # To set a quota set the "nextcloud_quota" property in the user's attributes
    "quota": user.group_attributes().get("nextcloud_quota", None),
    # To connect an already existing user, set the "nextcloud_user_id" property in the
    # user's attributes to the username of the corresponding user on Nextcloud.
    "user_id": user.attributes.get("nextcloud_user_id", str(user.uuid)),
}

Security Note!

Also be aware that by default new users in Authentik have access to all apps without a binding policy (e.g. to a group).

Admin OpenID Plugin Config in Nextcloud

Basically, you follow all the steps etc, then you go to https://nextcloud.domain/settings/admin/user_oidc

Make sure you:

• check Use Group Provisioning
• uncheck Use Unique User Id

You can do it like shown in the screenshot. Beware that otherwise another group "admin" with a different hash in the Nextcloud Database, causing duplicates and confusion, as your user would not be in the right admin group.

Security Note!

It is possible to whitelist certain groups, but this will not add new groups to Nextcloud. To make that happen fill the whitelist box below Use Group Provisioning e.g. with admin (and so on)

Authentik Login page only using the OpenID Nextcloud plugin

Finally, if you only want Authentik serving a login page, go into to the Nextcloud app directory (if you use a container exec into it) and run (as user www-data) ./occ config:app:set --value=0 user_oidc allow_multiple_user_backends

See also here

• Authentik group names get hashed nextcloud/user_oidc#751
• Nextcloud Admin group missconfiguration? #4745

@BeryJu