flarum / oauth-provider
Turn Flarum into an OAuth 2.0 / OpenID Connect provider.
Package info
github.com/flarum/oauth-provider
Type:flarum-extension
pkg:composer/flarum/oauth-provider
Fund package maintenance!
Requires
- flarum/core: ^2.1
- lcobucci/jwt: ^5.0
- league/oauth2-server: ^8.5
Requires (Dev)
- flarum/audit: *
- flarum/core: 2.x-dev
- flarum/gdpr: *
- flarum/suspend: *
- flarum/testing: ^2.0
Suggests
None
Provides
None
Conflicts
None
Replaces
None
This package is auto-updated.
Last update: 2026-11-01 17:16:34 UTC
README
Turns Flarum into an OAuth 2.0 authorization server and OpenID Connect provider, so other applications can let users sign in with their forum account and act on their behalf with the scopes they consent to.
Running behind a reverse proxy
Dynamic client registration (/oauth/register, 10 registrations per hour) and client metadata document fetches (20 per hour) are rate limited per client IP address. Flarum takes that address from REMOTE_ADDR and does not read X-Forwarded-For itself.
Behind a reverse proxy, load balancer or CDN, REMOTE_ADDR is the proxy's address unless the web server is told otherwise: every client then shares one rate limit bucket, and a single client can use it up for everyone. Configure the web server to restore the client's address from the forwarding header sent by your own proxies only, for example:
- nginx:
set_real_ip_from <proxy address or range>;andreal_ip_header X-Forwarded-For;(ngx_http_realip_module) - Apache:
RemoteIPHeader X-Forwarded-ForandRemoteIPTrustedProxy <proxy address or range>(mod_remoteip)
Never trust the header from any address: clients could then choose their own address and escape the limits.
Keys
The RSA key that signs access and ID tokens, and the key that encrypts authorization codes and refresh tokens, are generated on first use and stored in storage/oauth-provider/, readable by the web server user only. Include that directory in backups: losing it invalidates every issued token. Keep it out of anything served publicly.
When several servers or containers serve one forum, storage/oauth-provider/ must be shared between them and persist across deployments. Otherwise each one generates its own keys, and tokens issued by one are rejected by the others.