OAuth2 authentication for yesod
Go to file
patrick brisbin 6d3ddda0c9
Support hoauth2-2.0
The new major version improves the naming of the fields of the OAuth2
record type. This type is central to this library and we leak it freely.

Users who make their own plugins are expected to construct values of
this type to pass into our functions, this makes the new version
disruptive to our code and our users'.

We have two options:

1. Update and release our own new major version

   The major downside is that the current LTS resolver will then not
   update beyond our currently-released version. We have no immediate
   plans for new features in this library, but if we have bugs reported
   to be fixed we would either have to manage a complex backporting or
   ask our Stack users to wait for the next major LTS, which has
   historically been many months.

   Users who wish to use our new version would need to also bring in
   hoauth2, and who knows what else.

2. Release a fully-compatible update

   As mentioned, we leak OAuth2(..) through this library's interface. In
   order to be truly backwards-compatible, we would have to use CCP to
   define an "old style" OAuth2 and use that throughout, such that
   in-the-wild OAuth2 values continue to work as-is.

   This would not be a good long-term solution as it introduces a fair
   amount of naming confusion and will lead to import conflicts for any
   users who also import hoauth2-2.0 modules in the same project.

3. Release a mostly-compatible update

   This is the path this commit explores. We can update our own code to
   be hoauth2-2.0 compatible and use CPP to define the hoauth2-2.0-like
   OAuth2 if we're still on hoauth2-1.x.

   This gets us compiling in either case and "forward functional", with
   the exception of users who define their own plugins (which is rare).

   Because of that use-case, this should technically be a major version
   bump for ourselves (though I'm open to the argument we could treat
   the local-provider use-case differently), however it is still better
   than Option 1 in a few ways:

   - We still compile with hoauth2-1.x, so can be brought in easily as
     an isolated extra-dep
   - If there is a reported bug that we decide to only fix in the newer
     versions, the path for the user is better: they can pull us as an
     extra-dep and likely need no changes. Even if they're doing a
     custom plugin, the required changes are minor
2022-01-31 12:22:07 -05:00
.github/workflows Update GitHub Action to newer patterns 2022-01-31 12:22:07 -05:00
example Add ClassLink plugin 2021-01-14 10:21:46 -05:00
src Support hoauth2-2.0 2022-01-31 12:22:07 -05:00
test Project setup files 2018-01-23 10:16:22 -05:00
.env.example Add ClassLink plugin 2021-01-14 10:21:46 -05:00
.gitignore Update licensing and package metadata 2021-03-01 10:44:56 -05:00
.hlint.yaml Address HLint issues 2018-01-23 10:16:22 -05:00
.stylish-haskell.yaml Project setup files 2018-01-23 10:16:22 -05:00
CHANGELOG.md Actually release with no upper bounds 2021-05-13 14:55:32 -04:00
LICENSE Update licensing and package metadata 2021-03-01 10:44:56 -05:00
Makefile Update nightly CI 2020-12-21 08:40:43 -05:00
package.yaml Actually release with no upper bounds 2021-05-13 14:55:32 -04:00
README.md Support hoauth2-2.0 2022-01-31 12:22:07 -05:00
Setup.lhs Initial import 2013-07-14 11:11:44 +02:00
stack-lts-13.2.yaml Update to latest GHC, Stackage resolver, hoauth2 2020-08-24 10:49:14 -04:00
stack-lts-13.2.yaml.lock Update to latest GHC, Stackage resolver, hoauth2 2020-08-24 10:49:14 -04:00
stack-lts-16.10.yaml fixup! Update to latest GHC, Stackage resolver, hoauth2 2020-08-24 10:49:14 -04:00
stack-lts-16.10.yaml.lock fixup! Update to latest GHC, Stackage resolver, hoauth2 2020-08-24 10:49:14 -04:00
stack-lts-17.4.yaml Update default resolver, explicit GHC-8.10 CI 2021-03-01 10:44:56 -05:00
stack-lts-17.4.yaml.lock Update default resolver, explicit GHC-8.10 CI 2021-03-01 10:44:56 -05:00
stack.yaml Support hoauth2-2.0 2022-01-31 12:22:07 -05:00
stack.yaml.lock Support hoauth2-2.0 2022-01-31 12:22:07 -05:00
yesod-auth-oauth2.cabal Support hoauth2-2.0 2022-01-31 12:22:07 -05:00

Yesod.Auth.OAuth2

OAuth2 AuthPlugins for Yesod.

Usage

import Yesod.Auth
import Yesod.Auth.OAuth2.GitHub

instance YesodAuth App where
    -- ...

    authPlugins _ = [oauth2GitHub clientId clientSecret]

clientId :: Text
clientId = "..."

clientSecret :: Text
clientSecret = "..."

Some plugins, such as GitHub and Slack, have scoped functions for requesting additional information:

oauth2SlackScoped [SlackBasicScope, SlackEmailScope] clientId clientSecret

Working with Extra Data

We put the minimal amount of user data possible in credsExtra -- just enough to support you parsing or fetching additional data yourself.

For example, if you work with GitHub and GitHub user profiles, you likely already have a model and a way to parse the /user response. Rather than duplicate all that in our library, we try to make it easy for you to re-use that code yourself:

authenticate creds = do
    let
        -- You can run your own FromJSON parser on the response we already have
        eGitHubUser :: Either String GitHubUser
        eGitHubUser = getUserResponseJSON creds

        -- Avert your eyes, simplified example
        Just accessToken = getAccessToken creds
        Right githubUser = eGitHubUser

    -- Or make followup requests using our access token
    runGitHub accessToken $ userRepositories githubUser

    -- Or store it for later
    insert User
        { userIdent = credsIdent creds
        , userAccessToken = accessToken
        }

NOTE: Avoid looking up values in credsExtra yourself; prefer the provided get functions. The data representation itself is no longer considered public API.

Local Providers

If we don't supply a "Provider" (e.g. GitHub, Google, etc) you need, you can write your own using our provided Prelude:

import Yesod.Auth.OAuth2.Prelude

pluginName :: Text
pluginName = "mysite"

oauth2MySite :: YesodAuth m => Text -> Text -> AuthPlugin m
oauth2MySite clientId clientSecret =
    authOAuth2 pluginName oauth2 $ \manager token -> do
        -- Fetch a profile using the manager and token, leave it a ByteString
        userResponse <- -- ...

        -- Parse it to your preferred identifier, e.g. with Data.Aeson
        userId <- -- ...

        -- See authGetProfile for the typical case

        pure Creds
            { credsPlugin = pluginName
            , credsIdent = userId
            , credsExtra = setExtra token userResponse
            }
  where
    oauth2 = OAuth2
        { oauth2ClientId = clientId
        , oauth2ClientSecret = Just clientSecret
        , oauth2AuthorizeEndpoint = "https://mysite.com/oauth/authorize"
        , oauth2TokenEndpoint = "https://mysite.com/oauth/token"
        , oauth2RedirectUri = Nothing
        }

The Prelude module is considered public API, though we may build something higher-level that is more convenient for this use-case in the future.

Development & Tests

stack setup
stack build --dependencies-only
stack build --pedantic --test

Please also run HLint and Weeder before submitting PRs.


CHANGELOG | LICENSE