Support encrypted storage of SocialApp.client_secret credentials #4748

ArnavBallinCode commented 2026年05月29日 05:30:06 +02:00

Problem

allauth.socialaccount.models.SocialApp.secret currently stores OAuth client secrets in plaintext in the database.

Example:

SocialApp.objects.create(
 provider="google",
 client_id="...",
 secret="super-secret-client-secret"
)

The secret is directly readable by anyone with database access.

For many deployments this may be acceptable because the application must eventually access the plaintext secret to perform OAuth flows.

However, in multi-tenant SaaS deployments, OAuth credentials may be supplied by customers rather than platform operators.

Examples:

• Event organizers configuring their own Google OAuth application
• Organizations configuring their own Wikimedia OAuth application
• Enterprise customers configuring their own identity provider

In these cases, database administrators and platform operators can view customer-owned OAuth client secrets directly.

Question

Is plaintext storage of SocialApp.secret the intended design?

If so, what is the recommended approach for applications that want to:

• Encrypt OAuth client secrets at rest
• Support encryption key rotation
• Prevent accidental exposure in admin interfaces
• Remain compatible with future django-allauth upgrades

Current Situation

We are evaluating a solution that encrypts SocialApp.secret before persistence and transparently decrypts it when allauth accesses the provider configuration.

One implementation approach involves overriding SocialAccountAdapter.list_apps() and decrypting secrets at runtime.

However, this requires modifying behavior around the SocialApp model and potentially performing schema changes on the socialaccount_socialapp table.

Before proceeding further, we would like to understand whether django-allauth already provides a supported extension point or recommended pattern for protecting stored OAuth client secrets.

Possible Approaches

Some possibilities could include:

• First-class encrypted field support
• A pluggable secret storage backend
• Hooks for secret serialization/deserialization
• Official guidance on implementing encrypted storage externally

Expected Behavior

Ideally, applications should have a supported way to protect OAuth client secrets at rest while remaining compatible with future django-allauth releases.

Could the maintainers clarify:

1. Whether plaintext storage is an intentional design decision.
2. Whether encrypted storage is considered within scope for django-allauth.
3. What extension points are recommended for applications that need stronger secret protection.

## Problem `allauth.socialaccount.models.SocialApp.secret` currently stores OAuth client secrets in plaintext in the database. Example: ```python SocialApp.objects.create( provider="google", client_id="...", secret="super-secret-client-secret" ) ``` The secret is directly readable by anyone with database access. For many deployments this may be acceptable because the application must eventually access the plaintext secret to perform OAuth flows. However, in multi-tenant SaaS deployments, OAuth credentials may be supplied by customers rather than platform operators. Examples: - Event organizers configuring their own Google OAuth application - Organizations configuring their own Wikimedia OAuth application - Enterprise customers configuring their own identity provider In these cases, database administrators and platform operators can view customer-owned OAuth client secrets directly. ## Question Is plaintext storage of `SocialApp.secret` the intended design? If so, what is the recommended approach for applications that want to: - Encrypt OAuth client secrets at rest - Support encryption key rotation - Prevent accidental exposure in admin interfaces - Remain compatible with future django-allauth upgrades ## Current Situation We are evaluating a solution that encrypts `SocialApp.secret` before persistence and transparently decrypts it when allauth accesses the provider configuration. One implementation approach involves overriding `SocialAccountAdapter.list_apps()` and decrypting secrets at runtime. However, this requires modifying behavior around the `SocialApp` model and potentially performing schema changes on the `socialaccount_socialapp` table. Before proceeding further, we would like to understand whether django-allauth already provides a supported extension point or recommended pattern for protecting stored OAuth client secrets. ## Possible Approaches Some possibilities could include: - First-class encrypted field support - A pluggable secret storage backend - Hooks for secret serialization/deserialization - Official guidance on implementing encrypted storage externally ## Expected Behavior Ideally, applications should have a supported way to protect OAuth client secrets at rest while remaining compatible with future django-allauth releases. Could the maintainers clarify: 1. Whether plaintext storage is an intentional design decision. 2. Whether encrypted storage is considered within scope for django-allauth. 3. What extension points are recommended for applications that need stronger secret protection.

Rachit7168 commented 2026年05月30日 06:07:08 +02:00

I also had the same question

I also had the same question

pennersr commented 2026年05月30日 14:35:17 +02:00

You can avoid storing the SocialApp configuration in the database altogether by moving the apps into the settings (SOCIALACCOUNT_PROVIDERS). If that is not an option for your use case, then indeed currently these are stored unencrypted. What we can do there to improve is to offer encrypt()/decrypt() adapter methods (similar to what allauth.mfa has) and store/retrieve the secret using those methods. Then, in your project, you can override and choose whatever encryption you would like.

You can avoid storing the `SocialApp` configuration in the database altogether by moving the apps into the settings (``SOCIALACCOUNT_PROVIDERS``). If that is not an option for your use case, then indeed currently these are stored unencrypted. What we can do there to improve is to offer `encrypt()/decrypt()` adapter methods (similar to what `allauth.mfa` has) and store/retrieve the secret using those methods. Then, in your project, you can override and choose whatever encryption you would like.