[PR #203] [CLOSED] RFC: OIDC #953

New Issue

OVERLORD · 2026-02-04T21:40:29+03:00

OVERLORD commented

2026-02-04 21:40:29 +03:00

📋 Pull Request Information

Original PR: https://github.com/plankanban/planka/pull/203
Author: @lorenz
Created: 2/5/2022
Status: ❌ Closed

Base: master ← Head: oidc

📝 Commits (1)

71e7349 OIDC token exchange

📊 Changes

7 files changed (+154 additions, -9040 deletions)

View changed files

➕ server/api/controllers/access-tokens/exchange.js (+64 -0)
➕ server/api/hooks/oidc/index.js (+35 -0)
📝 server/config/custom.js (+6 -0)
📝 server/config/policies.js (+1 -0)
📝 server/config/routes.js (+1 -0)
📝 server/package-lock.json (+46 -9040)
📝 server/package.json (+1 -0)

📄 Description

This is a start at implementing a OIDC RP for Planka. It implements just the server side by exposing a token exchange endpoint where a client can exchange an OAuth2/OIDC code for a Planka access token. It auto-manages user attributes based on user info received from an OIDC-compliant IDP.

I have a client implementation working for me but it's extremely hacky so not included here.

There are a bunch of open questions left, that's why I'm posting this as a RFC:

How does the frontend figure out if OIDC is enabled and what the config is? Probably needs another API to ask for login configuration. Theoretically oidcIssuer and oidcClientId is all it needs, but we could just pass it a full authorization URL.
Is it a better idea to overload the POST /access-token call or keep the separate POST /access-token/exchange?
Is making password nullable better than storing '$sso$' in there?
username has a bunch of constraints on it which cannot be kept if we're going to store the OIDC subject (sub) in there. Alternative would be to have a dedicated field.
For a proper implementation this should lock managed user attributes from manual editing.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/plankanban/planka/pull/203 **Author:** [@lorenz](https://github.com/lorenz) **Created:** 2/5/2022 **Status:** ❌ Closed **Base:** `master` ← **Head:** `oidc` --- ### 📝 Commits (1) - [`71e7349`](https://github.com/plankanban/planka/commit/71e73494a55541bcbfac376452eec9de00d2e2fc) OIDC token exchange ### 📊 Changes **7 files changed** (+154 additions, -9040 deletions) <details> <summary>View changed files</summary> ➕ `server/api/controllers/access-tokens/exchange.js` (+64 -0) ➕ `server/api/hooks/oidc/index.js` (+35 -0) 📝 `server/config/custom.js` (+6 -0) 📝 `server/config/policies.js` (+1 -0) 📝 `server/config/routes.js` (+1 -0) 📝 `server/package-lock.json` (+46 -9040) 📝 `server/package.json` (+1 -0) </details> ### 📄 Description This is a start at implementing a OIDC RP for Planka. It implements just the server side by exposing a token exchange endpoint where a client can exchange an OAuth2/OIDC code for a Planka access token. It auto-manages user attributes based on user info received from an OIDC-compliant IDP. I have a client implementation working for me but it's extremely hacky so not included here. There are a bunch of open questions left, that's why I'm posting this as a RFC: * How does the frontend figure out if OIDC is enabled and what the config is? Probably needs another API to ask for login configuration. Theoretically `oidcIssuer` and `oidcClientId` is all it needs, but we could just pass it a full authorization URL. * Is it a better idea to overload the `POST /access-token` call or keep the separate `POST /access-token/exchange`? * Is making password nullable better than storing '$sso$' in there? * username has a bunch of constraints on it which cannot be kept if we're going to store the OIDC subject (sub) in there. Alternative would be to have a dedicated field. * For a proper implementation this should lock managed user attributes from manual editing. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

OVERLORD added the pull-request label 2026-02-04 21:40:29 +03:00

OVERLORD closed this issue

2026-02-04 21:40:30 +03:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/planka#953