OAuth 2.0 Identity Providers
Memos supports OAuth 2.0 for single sign-on (SSO) with external identity providers.Supported Providers
Any OAuth 2.0-compliant provider can be configured, including:- GitHub
- GitLab
- Microsoft Azure AD
- Okta
- Auth0
- Keycloak
- Custom OAuth 2.0 providers
OAuth Configuration
Identity providers are configured with the following parameters:Field Mapping
Memos extracts user information from the OAuth provider’s response using field mapping:The claim field for unique user identifier (e.g.,
sub, id, username). Required.The claim field for display name (e.g.,
name, display_name). Falls back to identifier if not provided.The claim field for email address (e.g.,
email, mail).The claim field for avatar/profile picture URL (e.g.,
picture, avatar_url).PKCE Support
Memos supports Proof Key for Code Exchange (PKCE) for enhanced security in the OAuth flow. When acode_verifier is provided during token exchange, it will be included in the request.
Example: GitHub OAuth
1. Register OAuth App on GitHub:- Go to Settings → Developer settings → OAuth Apps → New OAuth App
- Set Authorization callback URL:
https://your-memos.com/auth/callback - Copy Client ID and generate Client Secret
- Navigate to your Memos login page
- Click “Sign in with OAuth”
- Authorize with GitHub
- Memos will create or link the user account
Example: Google OAuth
1. Create OAuth credentials in Google Cloud Console:- Go to APIs & Services → Credentials
- Create OAuth 2.0 Client ID
- Set Authorized redirect URI:
https://your-memos.com/auth/callback
S3-Compatible Storage
Memos supports S3-compatible object storage for attachments and media files.Supported Providers
- Amazon S3
- MinIO
- DigitalOcean Spaces
- Cloudflare R2
- Backblaze B2
- Wasabi
- Any S3-compatible storage service
Storage Configuration
Configuration Parameters
AWS access key ID or equivalent for your S3 provider.
AWS secret access key or equivalent for your S3 provider.
S3 endpoint URL. For AWS S3, use
https://s3.{region}.amazonaws.com. For other providers, use their specific endpoint.Storage region (e.g.,
us-east-1, eu-west-1).Bucket name where files will be stored.
Use path-style URLs instead of virtual-hosted-style URLs. Set to
true for MinIO and some other providers.Storage Operations
Memos uses the AWS SDK v2 for Go and supports:- Upload: Files are uploaded with proper content type detection
- Download: Files are retrieved directly or via presigned URLs
- Delete: Files are removed when attachments are deleted
- Presigning: Generates temporary signed URLs valid for 5 days
Example: MinIO
Example: Cloudflare R2
Example: DigitalOcean Spaces
Storage Types
Memos supports three storage backends:1. Database Storage
- Simple setup, no external dependencies
- Automatic backups with database backups
- No additional configuration needed
- Database size grows quickly with media files
- Slower for large files
- Not recommended for production
2. Local Storage
- Fast access
- No external dependencies
- Good for self-hosted deployments
- Not suitable for multi-instance deployments
- Requires volume mounts in containerized environments
- No built-in CDN support
3. S3 Storage
- Scalable and reliable
- CDN integration available
- Suitable for multi-instance deployments
- Offloads storage from application server
- Requires external service
- Additional cost
- More complex configuration
Attachment Storage Flow
Upload Process
- Client uploads file via
/api/v1/attachmentsendpoint - Server validates file type and size
- Based on storage configuration:
- Database: Store blob in
attachmenttable - Local: Write file to
{data_dir}/attachments/{uid}/{filename} - S3: Upload to
s3://{bucket}/{key}using AWS SDK
- Database: Store blob in
- Create attachment record with storage metadata
- Return attachment resource to client
Access Process
- Database/Local: Files are served via
/file/attachments/{uid}/{filename} - S3: Files are served via presigned URLs valid for 5 days
- External: Direct reference URLs are used
Integration Management APIs
List Identity Providers
Create Identity Provider
Update Storage Settings
Security Considerations
OAuth 2.0
- Client secrets should be kept secure and never committed to version control
- Use HTTPS for all OAuth redirect URLs
- Validate the
stateparameter to prevent CSRF attacks - Consider enabling PKCE for public clients
- Restrict OAuth scopes to minimum required permissions
S3 Storage
- Use IAM roles with least privilege access
- Enable bucket versioning for data protection
- Configure bucket policies to restrict public access
- Use presigned URLs with short expiration times when possible
- Enable server-side encryption at rest
- Rotate access keys regularly
Troubleshooting
OAuth Login Fails
Possible causes:- Incorrect redirect URI in OAuth provider settings
- Invalid client ID or secret
- Missing required scopes
- Field mapping doesn’t match provider’s response
S3 Upload Fails
Possible causes:- Invalid credentials
- Incorrect bucket name or region
- Insufficient IAM permissions
- Network connectivity issues
- Wrong
usePathStylesetting
Presigned URLs Expire
Presigned S3 URLs are valid for 5 days. After expiration, clients need to fetch a new URL from the Memos API. Current behavior: Hard-coded 5-day expiration inplugin/storage/s3/s3.go:74
Workaround: For longer-lived URLs, consider using CloudFront or a CDN with custom URL signing.
Limitations
- OAuth 2.0 only (no SAML, LDAP, or other protocols)
- No automatic user provisioning from identity provider
- Storage type cannot be changed without manual migration
- Presigned S3 URLs have fixed 5-day expiration
- No support for multiple storage backends simultaneously
- Database storage not recommended for production use
Related Resources
- Authentication - Authentication mechanisms
- Attachment Resource - Attachment API
- Instance Settings - Configure integrations
- User Service - User management