- How do I install mpociot/socialite-slack?
- You would normally run composer require mpociot/socialite-slack, but the last release targets Socialite 3.0 from 2017, so the dependency constraint usually blocks resolution on modern Laravel and Socialite 5.x. The practical path is to require it on a scratch branch just to read the source, then copy the SlackProvider class into app/Socialite and register it with Socialite::extend('slack', ...). Treat the Composer install as a spike, not a production dependency.
- Does this package work with Laravel 9 or Socialite 5.x?
- No, not out of the box. The last release was 2017-08-17 and targets Socialite 3.0, so Composer will refuse to resolve it on Laravel 9+ with Socialite 5.x. You can fork the single provider class and update the getAuthUrl, getTokenUrl, getUserByToken, and mapUserToObject methods against the current Slack OAuth surface and the current Socialite contract. Budget one to two engineering days for the fork, verification, and a token-exchange test.
- What Slack app credentials and configuration does the provider need?
- The provider reads a client ID, client secret, and redirect URI, typically from a services.slack block in config/services.php fed by environment variables. You create a Slack app in the dashboard, configure the user scopes there, and add the exact redirect URI. Slack requires an exact redirect URI match, so trailing slashes and scheme mismatches are a common source of failures.
- Does it support Slack OAuth V2, bot tokens, or granular scopes?
- No. The code predates oauth.v2.access, granular scopes, token rotation, and Sign in with Slack / OIDC, and it has no Web API client, Events API support, or multi-workspace credential management. It expects the legacy users.identity payload with user.id and team.id, not V2's authed_user object. If you need bot scopes, message posting, or token rotation, this is a reference implementation only.
- Which Slack scopes does this provider request?
- It relies on legacy user identity scopes such as identity.basic, identity.email, identity.avatar, and identity.team configured in the Slack app dashboard rather than something the package manages for you. Verify that the dashboard scopes match what the provider sends during the authorize redirect. Modern Slack apps favor granular scopes, which this package does not handle.
- How do I get the Slack user's email and team from Socialite?
- After the callback, Socialite::driver('slack')->user() returns a mapped user object built from the legacy users.identity response. The default mapping exposes the Slack user ID and team ID, and the email is available only if identity.email is among your configured scopes. Because the response shape changed in newer Slack flows, check the mapping against a sandbox app before relying on any field.
- Is mpociot/socialite-slack still maintained?
- No. There have been no releases since 2017-08-17, there are zero dependents, and there is no upstream activity, so expect no security patches or compatibility fixes. The MIT license does mean vendoring is legally clean, which collapses the build-versus-buy decision into copying roughly 150 lines into your own codebase. Once forked and owned, the risk is bounded.
- What are the alternatives to this package for Slack login in Laravel?
- The main options are socialiteproviders/slack, writing a small custom Socialite provider, or using a direct Guzzle or OIDC client if you need Sign in with Slack. For a Laravel app already standardized on Socialite, a maintained provider is usually cheaper than owning a fork. For greenfield or OAuth V2 requirements, a small standalone client has comparable effort with fewer unknowns.
- Can I use this package for Sign in with Slack or OIDC?
- Not directly. The provider predates Slack's OIDC-based Sign in with Slack, so both the authorize and token exchanges and the user response mapping differ from current behavior. You would have to rewrite those methods and likely the user mapping before it works against a current Slack app. Use it as a reference for the handshake shapes, not as a working OIDC client.
- Should I add mpociot/socialite-slack to composer.json in production?
- Generally no. The safer pattern is to timebox a spike, fork the provider into app/Socialite, register it via Socialite::extend, and isolate it behind an internal adapter such as a SlackAuthService. That way your domain code depends on your own interface, and swapping to socialiteproviders/slack, a custom provider, or Slack OIDC becomes a one-file change. The spike exists to force that vendoring decision early rather than discovering incompatibility late.