[GH-ISSUE #3777] [SSO] Fetch SSO/SAML configuration #9721

Closed
opened 2026-04-13 05:23:35 -05:00 by GiteaMirror · 7 comments
Owner

Originally created by @TheUntraceable on GitHub (Aug 4, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3777

Originally assigned to: @Kinfe123 on GitHub.

Is this suited for github?

  • Yes, this is suited for github

Right now when you register an SSO provider you cannot fetch the current configuration to allow modifications.

Describe the solution you'd like

A function such as authClient.sso.get({organizationId: ...}) to retrieve the configuration for SSO/SAML

Describe alternatives you've considered

Manually writing your own endpoint to fetch the configuration from your database

Additional context

No response

Originally created by @TheUntraceable on GitHub (Aug 4, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3777 Originally assigned to: @Kinfe123 on GitHub. ### Is this suited for github? - [x] Yes, this is suited for github ### Is your feature request related to a problem? Please describe. Right now when you register an SSO provider you cannot fetch the current configuration to allow modifications. ### Describe the solution you'd like A function such as authClient.sso.get({organizationId: ...}) to retrieve the configuration for SSO/SAML ### Describe alternatives you've considered Manually writing your own endpoint to fetch the configuration from your database ### Additional context _No response_
GiteaMirror added the enhancementlocked labels 2026-04-13 05:23:36 -05:00
Author
Owner

@Kinfe123 commented on GitHub (Aug 5, 2025):

Currently, there's a way to fetch the registered spMetadata, but it's limited to service providers (SP). you can use

await auth.api.spMetadata({
   query: {
   	providerId: 'provider-id'
   }
})
<!-- gh-comment-id:3155164636 --> @Kinfe123 commented on GitHub (Aug 5, 2025): Currently, there's a way to fetch the registered spMetadata, but it's limited to service providers (SP). you can use ```ts await auth.api.spMetadata({ query: { providerId: 'provider-id' } }) ```
Author
Owner

@TheUntraceable commented on GitHub (Aug 6, 2025):

Currently, there's a way to fetch the registered spMetadata, but it's limited to service providers (SP). you can use

await auth.api.spMetadata({
 query: {
 	providerId: 'provider-id'
 }
})

But is there any way to get the configured SSO provider details?

<!-- gh-comment-id:3159611056 --> @TheUntraceable commented on GitHub (Aug 6, 2025): > Currently, there's a way to fetch the registered spMetadata, but it's limited to service providers (SP). you can use > > ```ts > await auth.api.spMetadata({ > query: { > providerId: 'provider-id' > } > }) > ``` But is there any way to get the configured SSO provider details?
Author
Owner

@Kinfe123 commented on GitHub (Aug 6, 2025):

You mean the ones stored in your ssoProvider table?

<!-- gh-comment-id:3159869073 --> @Kinfe123 commented on GitHub (Aug 6, 2025): You mean the ones stored in your ssoProvider table?
Author
Owner

@TheUntraceable commented on GitHub (Aug 7, 2025):

You mean the ones stored in your ssoProvider table?

Yeah. I want to get that data and present the OIDC config (in my case, also would be useful for SAML), so that users can edit it if needed and view it (or just check if SSO/SAML is even configured)

<!-- gh-comment-id:3165361518 --> @TheUntraceable commented on GitHub (Aug 7, 2025): > You mean the ones stored in your ssoProvider table? Yeah. I want to get that data and present the OIDC config (in my case, also would be useful for SAML), so that users can edit it if needed and view it (or just check if SSO/SAML is even configured)
Author
Owner

@Kinfe123 commented on GitHub (Aug 8, 2025):

If that is needed you can also do it at db level or orm if you do have that. But I will see the potential use case and will add it if that is something that is actually needed.

<!-- gh-comment-id:3168840373 --> @Kinfe123 commented on GitHub (Aug 8, 2025): If that is needed you can also do it at db level or orm if you do have that. But I will see the potential use case and will add it if that is something that is actually needed.
Author
Owner

@TheUntraceable commented on GitHub (Aug 8, 2025):

If that is needed you can also do it at db level or orm if you do have that. But I will see the potential use case and will add it if that is something that is actually needed.

Yeah, definitely I think I could make a PR for this. Right now in my app in the organisation plugin page it currently always prompts for SSO configuration as I can't check if any exists right now.

Would I have to filter out the client ID and client secret when returning it? And for when there is an organisation ID present should I limit it to admin roles? Not sure how to handle the permissions.

<!-- gh-comment-id:3169077414 --> @TheUntraceable commented on GitHub (Aug 8, 2025): > If that is needed you can also do it at db level or orm if you do have that. But I will see the potential use case and will add it if that is something that is actually needed. Yeah, definitely I think I could make a PR for this. Right now in my app in the organisation plugin page it currently always prompts for SSO configuration as I can't check if any exists right now. Would I have to filter out the client ID and client secret when returning it? And for when there is an organisation ID present should I limit it to admin roles? Not sure how to handle the permissions.
Author
Owner

@Kinfe123 commented on GitHub (Aug 8, 2025):

Dont you think this should be the thing that you have to internally do it. i dont think there could some source ambiguity on implementing this not the technical wise but somehow the data that we have to return but as long as it is not holding you back from implementing your features thats all good. but as i have said we will even welcome PR and see how people react on the feature. even from the issue.

<!-- gh-comment-id:3169169394 --> @Kinfe123 commented on GitHub (Aug 8, 2025): Dont you think this should be the thing that you have to internally do it. i dont think there could some source ambiguity on implementing this not the technical wise but somehow the data that we have to return but as long as it is not holding you back from implementing your features thats all good. but as i have said we will even welcome PR and see how people react on the feature. even from the issue.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#9721