🚀 Feature: Auto detect and populate callback URL #283

New Issue

OVERLORD · 2026-02-04T18:34:19+03:00

OVERLORD commented

2026-02-04 18:34:19 +03:00

Originally created by @mitchplze on GitHub (May 17, 2025).

Feature description

Request is to provide the option to automatically detect and populate the Callback URL when the field is left blank during initial OIDC client setup (or via checkmark/other mechanism).

This concept is borrowed from authentik:

When you create a new OAuth 2.0 provider and app in authentik and you leave the Redirect URI field empty, then the first time a user opens that app, authentik uses that URL as the saved redirect URL.

For this field:

Pitch

Depending on the client application and their documentation, it is often difficult to identify the exact callback URL for optimal security, while still allowing SSO with Pocket ID to work.
Sometimes callback URLs are randomly generated by the application, and not immediately apparent until the first authorization attempt.
With this feature, the first app to 'try' the OIDC connection after initially setting it up in Pocket - will win - and populate the client with the proper value.
Auto detecting this value is inherently more secure than using wildcards (where possible).
Potential challenge: the callback URL does not currently appear to be logged / visible in the UI.

Originally created by @mitchplze on GitHub (May 17, 2025). ### Feature description Request is to provide the option to automatically detect and populate the `Callback URL` when the field is left blank during initial OIDC client setup (or via checkmark/other mechanism). This concept is borrowed from [authentik](https://docs.goauthentik.io/docs/add-secure-apps/providers/oauth2/#additional-configuration-options-with-redirect-uris): > When you create a new OAuth 2.0 provider and app in authentik and you leave the Redirect URI field empty, then the first time a user opens that app, authentik uses that URL as the saved redirect URL. For this field: <img width="467" alt="Image" src="https://github.com/user-attachments/assets/c6792f1b-5476-4c79-a740-9391dea752e9" /> ### Pitch - Depending on the client application and their documentation, it is often difficult to identify the exact callback URL for optimal security, while still allowing SSO with Pocket ID to work. - Sometimes callback URLs are randomly generated by the application, and not immediately apparent until the first authorization attempt. - With this feature, the first app to 'try' the OIDC connection after initially setting it up in Pocket - will win - and populate the client with the proper value. - Auto detecting this value is inherently more secure than using wildcards (where possible). - Potential challenge: the callback URL does not currently appear to be logged / visible in the UI.

OVERLORD added the feature label 2026-02-04 18:34:19 +03:00

OVERLORD closed this issue

2026-02-04 18:34:21 +03:00

OVERLORD commented

2026-02-04 18:34:33 +03:00

@ItalyPaleAle commented on GitHub (May 19, 2025):

I like the suggestion of "TOFU" (Trust On First Use), but if the main problem is that the callback URL is sometimes hard to detect, how about we just show an error message saying callback url https://example.com is invalid?

@ItalyPaleAle commented on GitHub (May 19, 2025): I like the suggestion of "TOFU" (Trust On First Use), but if the main problem is that the callback URL is sometimes hard to detect, how about we just show an error message saying `callback url https://example.com is invalid`?

OVERLORD commented

2026-02-04 18:34:36 +03:00

@kmendell commented on GitHub (May 19, 2025):

I like the suggestion of "TOFU" (Trust On First Use), but if the main problem is that the callback URL is sometimes hard to detect, how about we just show an error message saying callback url https://example.com is invalid?

An error is already thrown and showed if the callback url is not right, im confused on what you're suggesting by this.

@kmendell commented on GitHub (May 19, 2025): > I like the suggestion of "TOFU" (Trust On First Use), but if the main problem is that the callback URL is sometimes hard to detect, how about we just show an error message saying `callback url https://example.com is invalid`? An error is already thrown and showed if the callback url is not right, im confused on what you're suggesting by this.

OVERLORD commented

2026-02-04 18:34:38 +03:00

@ItalyPaleAle commented on GitHub (May 19, 2025):

I like the suggestion of "TOFU" (Trust On First Use), but if the main problem is that the callback URL is sometimes hard to detect, how about we just show an error message saying callback url https://example.com is invalid?

An error is already thrown and showed if the callback url is not right, im confused on what you're suggesting by this.

The error just says Invalid callback URL, it might be necessary for an admin to fix this. I'm suggesting expanding to something like:

The callback URL https://example.com/callback is not valid for the application client-id, it might be necessary for an admin to fix this.

So the user has all the context they need to fix the issue.

@ItalyPaleAle commented on GitHub (May 19, 2025): > > I like the suggestion of "TOFU" (Trust On First Use), but if the main problem is that the callback URL is sometimes hard to detect, how about we just show an error message saying `callback url https://example.com is invalid`? > > An error is already thrown and showed if the callback url is not right, im confused on what you're suggesting by this. The error just says `Invalid callback URL, it might be necessary for an admin to fix this`. I'm suggesting expanding to something like: >The callback URL `https://example.com/callback` is not valid for the application `client-id`, it might be necessary for an admin to fix this. So the user has all the context they need to fix the issue.

OVERLORD commented

2026-02-04 18:34:44 +03:00

@mitchplze commented on GitHub (May 19, 2025):

I'm not sure what causes the error y'all are talking about to be thrown in any case.

The box seems to accept anything:

EDIT: Ah, I see, when you actually try and login you mean with an incorrect URL.

Would be super handy to have that in the error, yes. Right now there is no way I'm aware of to get the callback URL in the UI.

@mitchplze commented on GitHub (May 19, 2025): I'm not sure what causes the error y'all are talking about to be thrown in any case. The box seems to accept anything: <img width="968" alt="Image" src="https://github.com/user-attachments/assets/6ceaed0a-9fb3-442f-9046-46e258f62fb3" /> EDIT: Ah, I see, when you actually try and login you mean with an incorrect URL. Would be super handy to have that in the error, yes. Right now there is no way I'm aware of to get the callback URL in the UI.

OVERLORD commented

2026-02-04 18:34:55 +03:00

@kmanwar89 commented on GitHub (May 26, 2025):

Threw my upvote into the ring here -- what I noticed is you can't create the app until the callback is provided, but some apps don't provide you the callback until the IdP is configured, so it becomes chicken/egg.

I got around this by using a placeholder value (testing.whatever.com), filled out the remaining values in my client, then came back to override the callback URL once I had the true values.

@kmanwar89 commented on GitHub (May 26, 2025): Threw my upvote into the ring here -- what I noticed is you can't create the app until the callback is provided, but some apps don't provide you the callback until the IdP is configured, so it becomes chicken/egg. I got around this by using a placeholder value (testing.whatever.com), filled out the remaining values in my client, then came back to override the callback URL once I had the true values.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id#283