JWT login microservice with plugable backends such as OAuth2, Google, Github, htpasswd, osiam, ..

Overview

loginsrv

loginsrv is a standalone minimalistic login server providing a JWT login for multiple login backends.

Docker Build Status Go Report Card Coverage Status Join the chat at https://gitter.im/tarent/loginsrv

** Attention: Update to v1.3.0 for Google Login Update !!!! **

Google will stop support for the Google+ APIs. So we changed loginsrv to use the standard oauth endpoints for Google login. Please update loginsrv to v1.3.0 if you are using google login.

** Attention: Since v1.3.0, pure HTTP is not supported by default **

Since v1.3.0, loginsrv sets the secure flag for the login cookie. So, if you use HTTP fo connect with the browser, e.g. for testing, you browser will ignore the cookie. Use the flag -cookie-secure=false when testing without HTTPS.

Abstract

Loginsrv provides a minimal endpoint for authentication. The login is performed against the providers and returned as a JSON Web Token (JWT). It can be used as:

  • Standalone microservice
  • Docker container
  • Golang library
  • Caddy plugin. (See caddy/README.md for details)

Supported Provider Backends

The following providers (login backends) are supported.

Questions

For questions and support please use the Gitter chat room.

Join the chat at https://gitter.im/tarent/loginsrv

Configuration and Startup

Config Options

Note for Caddy users: Not all parameters are available in Caddy. See the table for details. With Caddy, the parameter names can also be used with _ in the names, e.g. cookie_http_only.

Parameter Type Default Caddy Description
-cookie-domain string X Optional domain parameter for the cookie
-cookie-expiry string session X Expiry duration for the cookie, e.g. 2h or 3h30m
-cookie-http-only boolean true X Set the cookie with the HTTP only flag
-cookie-name string "jwt_token" X Name of the JWT cookie
-cookie-secure boolean true X Set the secure flag on the JWT cookie. (Set this to false for plain HTTP support)
-github value X OAuth config in the form: client_id=..,client_secret=..[,scope=..][,redirect_uri=..]
-google value X OAuth config in the form: client_id=..,client_secret=..[,scope=..][,redirect_uri=..]
-bitbucket value X OAuth config in the form: client_id=..,client_secret=..[,scope=..][,redirect_uri=..]
-facebook value X OAuth config in the form: client_id=..,client_secret=..[,scope=..][,redirect_uri=..]
-gitlab value X OAuth config in the form: client_id=..,client_secret=..[,scope=..,][redirect_uri=..]
-host string "localhost" - Host to listen on
-htpasswd value X Htpasswd login backend opts: file=/path/to/pwdfile
-jwt-expiry go duration 24h X Expiry duration for the JWT token, e.g. 2h or 3h30m
-jwt-secret string "random key" X Secret used to sign the JWT token. (See caddy/README.md for details.)
-jwt-secret-file string X File to load the jwt-secret from, e.g. /run/secrets/some.key. Takes precedence over jwt-secret!
-jwt-algo string "HS512" X Signing algorithm to use (ES256, ES384, ES512, RS256, RS384, RS512, HS256, HS384, HS512)
-log-level string "info" - Log level
-login-path string "/login" X Path of the login resource
-logout-url string X URL or path to redirect to after logout
-osiam value X OSIAM login backend opts: endpoint=..,client_id=..,client_secret=..
-port string "6789" - Port to listen on
-redirect boolean true X Allow dynamic overwriting of the the success by query parameter
-redirect-query-parameter string "backTo" X URL parameter for the redirect target
-redirect-check-referer boolean true X Check the referer header to ensure it matches the host header on dynamic redirects
-redirect-host-file string "" X A file containing a list of domains that redirects are allowed to, one domain per line
-simple value X Simple login backend opts: user1=password,user2=password,..
-success-url string "/" X URL to redirect to after login
-template string X An alternative template for the login form
-text-logging boolean true - Log in text format instead of JSON
-jwt-refreshes int 0 X The maximum number of JWT refreshes
-grace-period go duration 5s - Duration to wait after SIGINT/SIGTERM for existing requests. No new requests are accepted.
-user-file string X A YAML file with user specific data for the tokens. (see below for an example)
-user-endpoint string X URL of an endpoint providing user specific data for the tokens. (see below for an example)
-user-endpoint-token string X Authentication token used when communicating with the user endpoint
-user-endpoint-timeout go duration 5s X Timeout used when communicating with the user endpoint

Environment Variables

All of the above Config Options can also be applied as environment variables by using variables named this way: LOGINSRV_OPTION_NAME. So e.g. jwt-secret can be set by environment variable LOGINSRV_JWT_SECRET.

Startup Examples

The simplest way to use loginsrv is by the provided docker container. E.g. configured with the simple provider:

$ docker run -d -p 8080:8080 tarent/loginsrv -cookie-secure=false -jwt-secret my_secret -simple bob=secret

$ curl --data "username=bob&password=secret" 127.0.0.1:8080/login
eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJib2IifQ.uWoJkSXTLA_RvfLKe12pb4CyxQNxe5_Ovw-N5wfQwkzXz2enbhA9JZf8MmTp9n-TTDcWdY3Fd1SA72_M20G9lQ

The same configuration could be written with environment variables this way:

$ docker run -d -p 8080:8080 -E COOKIE_SECURE=false -e LOGINSRV_JWT_SECRET=my_secret -e LOGINSRV_BACKEND=provider=simple,bob=secret tarent/loginsrv

API

GET /login

Per default, it returns a simple bootstrap styled login form for unauthenticated requests and a page with user info for authenticated requests. When the call accepts a JSON output, the json content of the token is returned to authenticated requests.

The returned HTML follows the UI composition conventions from (lib-compose)[https://github.com/tarent/lib-compose], so it can be embedded into an existing layout.

Parameter-Type Parameter Description
Http-Header Accept: text/html Return the login form or user html. default
Http-Header Accept: application/json Return the user Object as json, or 403 if not authenticated.

GET /login/

Starts the OAuth Web Flow with the configured provider. E.g. GET /login/github redirects to the GitHub login form.

POST /login

Performs the login and returns the JWT. Depending on the content-type and parameters, a classical JSON-Rest or a redirect can be performed.

Runtime Parameters

Parameter-Type Parameter Description
Http-Header Accept: text/html Set the JWT as a cookie named 'jwt_token' default
Http-Header Accept: application/jwt Returns the JWT within the body. No cookie is set
Http-Header Content-Type: application/x-www-form-urlencoded Expect the credentials as form encoded parameters default
Http-Header Content-Type: application/json Take the credentials from the provided JSON object
Post-Parameter username The username
Post-Parameter password The password
Get or Post backTo Dynamic redirect target after login (see (Redirects)[#redirects]) -success-url

Possible Return Codes

Code Meaning Description
200 OK Successfully authenticated
403 Forbidden The credentials are wrong
400 Bad Request Missing parameters
500 Internal Server Error Internal error, e.g. the login provider is not available or failed
303 See Other Sets the JWT as a cookie, if the login succeeds and redirect to the URLs provided in redirectSuccess or redirectError

Hint: The status 401 Unauthorized is not used as a return code to not conflict with an HTTP Basic authentication.

JWT-Refresh

If the POST-Parameters for username and password are missing and a valid JWT-Cookie is part of the request, then the JWT-Cookie is refreshed. This only happens if the jwt-refreshes config option is set to a value greater than 0.

DELETE /login

Deletes the JWT cookie.

For simple usage in web applications, this can also be called by GET|POST /login?logout=true

API Examples

Example:

Default is to return the token as Content-Type application/jwt within the body.

curl -i --data "username=bob&password=secret" http://127.0.0.1:6789/login
HTTP/1.1 200 OK
Content-Type: application/jwt
Date: Mon, 14 Nov 2016 21:35:42 GMT
Content-Length: 100

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJib2IifQ.-51G5JQmpJleARHp8rIljBczPFanWT93d_N_7LQGUXU

Example: Credentials as JSON

The credentials can also be sent JSON encoded.

curl -i -H 'Content-Type: application/json'  --data '{"username": "bob", "password": "secret"}' http://127.0.0.1:6789/login
HTTP/1.1 200 OK
Content-Type: application/jwt
Date: Mon, 14 Nov 2016 21:35:42 GMT
Content-Length: 100

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJib2IifQ.-51G5JQmpJleARHp8rIljBczPFanWT93d_N_7LQGUXU

Example: web based flow with 'Accept: text/html'

Sets the JWT as a cookie and redirects to a web page.

curl -i -H 'Accept: text/html' --data "username=bob&password=secret" http://127.0.0.1:6789/login
HTTP/1.1 303 See Other
Location: /
Set-Cookie: jwt_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJib2IifQ.-51G5JQmpJleARHp8rIljBczPFanWT93d_N_7LQGUXU; HttpOnly

Example: AJAX call with JQuery to fetch a JWT token and create a cookie from it

Creates a cookie from a successful API call to login.

$.ajax({
	url: "http://localhost:8080/login",
	type: 'POST',
	dataType: 'text',
	contentType: 'application/json',
	data: JSON.stringify( { 
		'username': 'demo', 
		'password': 'demo'
	}),
	success: function(data) {
		document.cookie = "jwt_token=" + data + ";path=/";
	},
	error: function (xhr, ajaxOptions, thrownError) {
	}
});

Make sure your main page has JQuery:

<script src="https://code.jquery.com/jquery-3.3.1.min.js"></script>

Redirects

The API has support for a redirect query parameter, e.g. ?backTo=/dynamic/return/path. For security reasons, the default behaviour is very restrictive:

  • Only local redirects (same host) are allowed.
  • The Referer header is checked to ensure that the call to the login page came from the same page.

These restrictions are there, to prevent you from unchecked redirect attacks, e.g. phishing or login attacks. If you know, what you are doing, you can disable the Referer check with --redirect-check-referer=false and provide a whitelist file for allowed external domains with --redirect-host-file=/some/domains.txt.

The JWT Token

Depending on the provider, the token may look as follows:

{
  "sub": "smancke",
  "picture": "https://avatars2.githubusercontent.com/u/4291379?v=3",
  "name": "Sebastian Mancke",
  "email": "[email protected]",
  "origin": "github"
}

Provider Backends

Htpasswd

Authentication against htpasswd file. MD5, SHA1 and Bcrypt are supported. But we recommend to only use Bcrypt for security reasons (e.g. htpasswd -B -C 15).

Parameters for the provider:

Parameter-Name Description
file Path to the password file (multiple files can be used by separating them with ';')

Example:

loginsrv -htpasswd file=users

Httpupstream

Authentication against an upstream HTTP server by performing a HTTP Basic authentication request and checking the response for a HTTP 200 OK status code. Anything other than a 200 OK status code will result in a failure to authenticate.

Parameters for the provider:

Parameter-Name Description
upstream HTTP/HTTPS URL to call
skipverify True to ignore TLS errors (optional, false by default)
timeout Request timeout (optional 1m by default, go duration syntax is supported)

Example:

loginsrv -httpupstream upstream=https://google.com,timeout=1s

OSIAM

OSIAM is a secure identity management solution providing REST based services for authentication and authorization. It implements the multiple OAuth2 flows, as well as SCIM for managing the user data.

To start loginsrv against the default OSIAM configuration on the same machine, use the following example.

loginsrv --jwt-secret=jwtsecret --text-logging -osiam endpoint=http://localhost:8080,client_id=example-client,client_secret=secret'

Then go to http://127.0.0.1:6789/login and login with admin/koala.

Simple

Simple is a demo provider for testing only. It holds a user/password table in memory.

Example

loginsrv -simple bob=secret

OAuth2

The OAuth Web Flow (aka 3-legged-OAuth flow) is also supported. Currently the following OAuth provider is supported:

  • GitHub
  • Google
  • Bitbucket
  • Facebook
  • Gitlab

An OAuth provider supports the following parameters:

Parameter-Name Description
client_id OAuth Client ID
client_secret OAuth Client Secret
scope Space separated scope List (optional)
redirect_uri Alternative Redirect URI (optional)

When configuring the OAuth parameters at your external OAuth provider, a redirect URI has to be supplied. This redirect URI has to point to the path /login/<provider>. If not supplied, the OAuth redirect URI is calculated out of the current URL. This should work in most cases and should even work if loginsrv is routed through a reverse proxy, if the headers X-Forwarded-Host and X-Forwarded-Proto are set correctly.

GitHub Startup Example

$ docker run -p 80:80 tarent/loginsrv -github client_id=xxx,client_secret=yyy

Templating

A custom template can be supplied by the parameter template. You can find the original template in login/login_form.go.

The templating uses the Golang template package. A short intro can be found here.

When you specify a custom template, only the layout of the original template is replaced. The partials of the original are still loaded into the template context and can be used by your template. So a minimal unstyled login template could look like this:

<!DOCTYPE html>
<html>
  <head>
      <!-- your styles -->
  <head>
  <body>
      <!-- your header -->

      {{ if .Error}}
        <div class="alert alert-danger" role="alert">
          <strong>Internal Error. </strong> Please try again later.
        </div>
      {{end}}

      {{if .Authenticated}}

         {{template "userInfo" . }}

      {{else}}

        {{template "login" . }}

      {{end}}

      <!-- your footer -->
  </body>
</html>

Custom claims

To customize the content of the JWT token either a file wich contains user data or an endpoint providing claims can be provided.

User file

A user file is a YAML file which contains additional information which is encoded in the token. After successful authentication against a backend system, the user is searched within the file and the content of the claims parameter is used to enhance the user JWT claim parameters.

To match an entry, the user file is searched in linear order and all attributes has to match the data of the authentication backend. The first matching entry will be used and all parameters below the claim attribute are written into the token. The following attributes can be used for matching:

  • sub - the username (all backends)
  • origin - the provider or backend name (all backends)
  • email - the mail address (the OAuth provider)
  • domain - the domain (Google only)
  • groups - the full path string of user groups enclosed in an array (Gitlab only)

Example:

  • The user bob will become the "role": "superAdmin", when authenticating with htpasswd file
  • The user [email protected] will become "role": "admin" and "projects": ["example"], when authenticating with Google OAuth
  • All other Google users with the domain example will become "role": "user" and "projects": ["example"]
  • All other Gitlab users with group example/subgroup and othergroup will become "role": "admin".
  • All others will become "role": "unknown", independent of the authentication provider
- sub: bob
  origin: htpasswd
  claims:
    role: superAdmin

- email: [email protected]
  origin: Google
  claims:
    role: admin
    projects:
      - example

- domain: example.org
  origin: Google
  claims:
    role: user
    projects:
      - example

- groups:
    - example/subgroup
    - othergroup
  origin: gitlab
  claims:
    role: admin

- claims:
    role: unknown

User endpoint

A user endpoint is a http endpoint which provides additional information on an authenticated user. After successful authentication against a backend system, the endpoint gets called and the provided information is used to enhance the user JWT claim parameters.

loginsrv passes these parameters to the endpoint:

  • sub - the username (all backends)
  • origin - the provider or backend name (all backends)
  • email - the mail address (the OAuth provider)
  • domain - the domain (Google only)
  • groups - the full path string of user groups enclosed in an array (Gitlab only)

An interaction looks like this

GET /claims?origin=google&[email protected]&[email protected] HTTP/1.1
Host: localhost:8080
Accept: */*
Authorization: Bearer token

HTTP/1.1 200 OK
Content-Type: application/json

{
  "sub":"[email protected]",
  "uid":"113",
  "origin":"google",
  "permissions": ["read", "write"]
}
Issues
  • Caddy - Use {user} placeholder for logs #32

    Caddy - Use {user} placeholder for logs #32

    I tested it on Windows 7 x64 and it works.

    I've not added tests yet.

    @smancke please review it. I'm unsure if it is the best way to add this feature.

    opened by magikstm 20
  • Dynamic success URL

    Dynamic success URL

    I think it would be great if the success URL could be set on a case-by-case basis, as a parameter. Useful when the user has been redirected to the authentication flow automatically—they can then be dropped back on the original URL they were trying to visit, after successfully authenticating.

    For username/password-based authentication, I imagine it as a GET parameter on the /login endpoint: /login?return=%2Fmyaccount. A hidden input field with the same value could be added to the form, sending it on as a POST parameter when the authentication is performed. I imagine something similar could be done for the third party service-based authentication methods, for example passing the value of the return parameter as the redirect_uri for GitHub OAUTH. The existing success-url config entry could be used as a fallback if no return parameter is set.

    opened by jsahlen 19
  • Caddy+Portainer behind oauth2

    Caddy+Portainer behind oauth2

    How can I deploy Portainer on Caddy behind oauth2.

    Portainer is running under subdomain, like portainer.domain.com. When trying to login, seems like javascript is throwing error, being redirected to auth, although I have authenticated. Portainer runs fine under localhost. Any suggestions? Thanks!

    opened by xmflsct 12
  • Dynamic redirects

    Dynamic redirects

    In reference to: https://github.com/tarent/loginsrv/issues/45

    Dynamic redirects are allowed by default. Referer is checked to make sure it matches the host by default. Redirects to external domains are blocked by default. A Whitelist file can be provided with one domain per line to allow redirects to external domains.

    opened by lhopki01 10
  • Include JWT in the redirect URL

    Include JWT in the redirect URL

    If I set backTo=https://myservice.com/somepage?jwt=[token] on my redirect, I'd like for the JWT to be included in the URL. Is this something that you'd accept a PR for? Or is this functionality already present in loginsrv?

    This functionality would open up a lot of opportunities for me to use loginsrv!

    opened by cweagans 10
  • Add new provider - SAML via Azure AD

    Add new provider - SAML via Azure AD

    Resolves: #168

    opened by greenpau 8
  • oauth2: got http status 403 on google get user info

    oauth2: got http status 403 on google get user info

    Caddyfile:

    localhost:3000 {
      proxy / localhost:3040
      jwt {
        path /
        allow domain readdle.com
      }
      login {
        google "client_id=***,client_secret=***,scope=https://www.googleapis.com/auth/userinfo.profile"
      }
    }
    

    Upon login it shows "Internal error" and an error in log: oauth2: got http status 403 on google get user info

    Also tried these scopes: https://www.googleapis.com/auth/plus.me, https://www.googleapis.com/auth/plus.login with same effect.

    Client ID and Client Secret are created for a fresh sample project. Same Client ID and secret work for bitly/oauth2_proxy, but I'd prefer to use caddy+loginsrv in our setup.

    opened by dobegor 8
  • Remove undocumented

    Remove undocumented "files" parameter for htpasswd and enhance doc

    This is a fix for #39.

    It removes an undocumented parameter and enhances the doc in the main page on a related feature.

    waiting on others 
    opened by magikstm 7
  • Caddy's import path has changed

    Caddy's import path has changed

    Caddy's import path (and Go module name) has changed from

    github.com/mholt/caddy
    

    to

    github.com/caddyserver/caddy
    

    Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

    I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

    I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

    This bash script should make it easy (run it from your project's top-level directory):

    find . -name '*.go' | while read -r f; do
    	sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
    done
    

    We use this script in the build server as part of the temporary workaround.

    Let me know if you have any questions! Sorry again for the inconvenience.

    opened by mholt 7
  • CORS issue for local dev

    CORS issue for local dev

    Hi all,

    I am trying to use the loginsrv on my local machine. My frontend is calling the API using localhost but I get :

    Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at http://localhost:8090/login

    The login works in command line: curl --data "[email protected]&password=azerty" 127.0.0.1:8090/login eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJhQGIuYyIsIm9yaWdpbiI6InNpbXBsZSIsImV4cCI6MTYyMTg1NjE1Mn0.U9uut1eHE2C1aHYW6Z00wAl8WLe0Xvy1nacSlAf2Pr3A8jh29ecNgjAB5ipHbpuit_30YRROALYCHZnsA2xnsw

    I've been reading about the CORS issue, and it says that the response header should contain Access-Control-Allow-Origin = http://localhost:4200 but I don't know where I can configure that ?

    opened by deltawi 0
  • Has anyone tried to integrate with Vault or any interest in doing so?

    Has anyone tried to integrate with Vault or any interest in doing so?

    Has anyone tried to integrate with Vault as a secrets store or any interest in doing so?

    opened by gc-ss 1
  • Add kid header

    Add kid header

    Continued from https://github.com/tarent/loginsrv/pull/160

    opened by kernle32dll 1
  • Cookie SameSite attribute

    Cookie SameSite attribute

    SInce Go 1.11, the Cookie struct has SameSite attribute in it to prevent CSRF attacks. I think loginsrv need to provide -cookie-samesite option.

    opened by JesusIslam 0
  • LinkedIn OAuth2 Login

    LinkedIn OAuth2 Login

    I just added LinkedIn OAuth2 login provider. Please review the PR. Thank you.

    opened by JesusIslam 1
  • Add new provider - SAML via Azure AD

    Add new provider - SAML via Azure AD

    Currently, the is no SAML backend. I want to open this issue to work on it to support Azure AD workflow.

    In Azure, there is an ability to create an application registration. When Azure users click on the icon associated with the application, they get redirected to a configurable URL, e.g. caddy proxy.

    The redirected response could be a POST containing SAML payload.

    Here, in case of AWS, it looks like this.

    image

    Once the caddy plugin gets the request, it validates the SAML payload and logs the user in.

    opened by greenpau 0
  • Caddy 2 port

    Caddy 2 port

    Is a port of loginsrv for Caddy 2 planned?

    Related discussion: Caddy JWT plugin - https://github.com/BTBurke/caddy-jwt/issues/57

    Related module in v2: https://github.com/caddyserver/caddy/tree/v2/modules/caddyhttp/caddyauth

    opened by magikstm 6
  • Doc suggestion - Add more example usage as a Standalone microservice

    Doc suggestion - Add more example usage as a Standalone microservice

    I suggest adding a few example usage of loginsrv as a Standalone microservice on the main page.

    I think these should be added:

    • Basics (help being available with loginsrv -help)
    • HTTPd (Apache)
    • NGINX
    • Caddy 1
    • Caddy 2
    opened by magikstm 0
  • Update Dockerfile for fully static build

    Update Dockerfile for fully static build

    This updates the docker build, to be fully static, and not contain anything else. While this greatly reduced the image size (to just under 9mb, from 18mb), the flip side is losing the ability to do anything useful in a running container (as there are no tools available, courtesy of the scratch image).

    opened by kernle32dll 1
  • When using asymmetric encryption a kid header is convenient so JSON Web Key Sets can be used

    When using asymmetric encryption a kid header is convenient so JSON Web Key Sets can be used

    Ideally loginsrv would just create a JSON Web Key Set and serve it up, but this is a a quick and easy fix for now. This was inspired by Auth0

    opened by vanpelt 3
Releases(v1.3.1)
  • v1.3.0(Jan 19, 2019)

    • ATTENTION: Added a config option to set the secure flag for cookies (default: -cookie-secure=true). If you run unsecure HTTP you have to set this option ot false!!!
    • Google OAuth provider now uses the google userinfo endpoint. No need to activate the google+ APIs anymore.
    • Added Gitlab OAuth Provider
    • The GET endpoint now returns the user info if the call accepts JSON
    • Default OAuth scopes for google and facebook provider. No need to configure them anymore.
    • Caddy-plugin: let upstream middleware (e.g. fastcgi and cgi) know about authenticated user
    • Caddy-plugin: fixed corner cases in handling of JWT_SECRET paramter for caddy
    • Add viewport meta tag to get proper scaling on mobile
    Source code(tar.gz)
    Source code(zip)
  • v1.2.4(Apr 9, 2018)

    • Facebook OAuth provider
    • Support for custom claims in a user file
    • Support for elliptic curve signing methods
    • Dynamic redirects
    • Some minor cleanups
    Source code(tar.gz)
    Source code(zip)
  • v1.2.3(Nov 14, 2017)

    • Bitbucket OAuth provider
    • Fix for default secret in caddy plugin
    • Replacement of {user} placeholder in caddy logs
    • Add domain to google oauth jwt
    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Aug 17, 2017)

  • v1.0.0(May 31, 2017)

    • Official Caddyserver release
    • Implement simple jwt refreshing
    • Added refresh for htaccess file
    • Added github login
    • Implemented graceful shutdown
    Source code(tar.gz)
    Source code(zip)
Owner
tarent
tarent solutions GmbH
tarent
This package provides json web token (jwt) middleware for goLang http servers

jwt-auth jwt auth middleware in goLang. If you're interested in using sessions, checkout my sessions library! README Contents: Quickstart Performance

Adam Hanna 206 Sep 21, 2021
The easiest JWT library to GO

JWT Go The easiest JWT Library that could be a starting point for your project. Installation go get github.com/supanadit/jwt-go Quick Start package ma

Supan Adit Pratama 16 Apr 21, 2021
A reverse proxy that provides authentication with Google, Github or other providers.

A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain or group.

OAuth2 Proxy 4.1k Sep 21, 2021
A reverse proxy that provides authentication with Google, Github or other providers.

A reverse proxy and static file server that provides authentication using Providers (Google, GitHub, and others) to validate accounts by email, domain

OAuth2 Proxy 4.1k Sep 19, 2021
A go implementation of JSON Web Tokens

jwt-go A go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens NEW VERSION COMING: There have been a lot of improvements s

null 941 Sep 23, 2021
A standalone, specification-compliant, OAuth2 server written in Golang.

Go OAuth2 Server This service implements OAuth 2.0 specification. Excerpts from the specification are included in this README file to describe differe

Richard Knop 1.8k Sep 16, 2021
an SSO and OAuth / OIDC login solution for Nginx using the auth_request module

Vouch Proxy An SSO solution for Nginx using the auth_request module. Vouch Proxy can protect all of your websites at once. Vouch Proxy supports many O

Vouch 1.5k Sep 21, 2021
Golang implementation of JSON Web Tokens (JWT)

jwt-go A go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens NEW VERSION COMING: There have been a lot of improvements s

Dave Grijalva 9.9k Sep 24, 2021
simple-jwt-provider - Simple and lightweight provider which exhibits JWTs, supports login, password-reset (via mail) and user management.

Simple and lightweight JWT-Provider written in go (golang). It exhibits JWT for the in postgres persisted user, which can be managed via api. Also, a password-reset flow via mail verification is available. User specific custom-claims also available for jwt-generation and mail rendering.

Max 20 Aug 2, 2021
This is an implementation of JWT in golang!

jwt This is a minimal implementation of JWT designed with simplicity in mind. What is JWT? Jwt is a signed JSON object used for claims based authentic

John Rowley 92 Aug 25, 2021
JSON Web Token library

About … a JSON Web Token (JWT) library for the Go programming language. Feature complete Full test coverage Dependency free Key management The API enf

Pascal S. de Kloe 269 Sep 26, 2021
Safe, simple and fast JSON Web Tokens for Go

jwt JSON Web Token for Go RFC 7519, also see jwt.io for more. The latest version is v3. Rationale There are many JWT libraries, but many of them are h

cristaltech 289 Sep 24, 2021
The boss of http auth.

Authboss Authboss is a modular authentication system for the web. It has several modules that represent authentication and authorization features that

Volatile Technologies Inc. 2.8k Sep 14, 2021
Go login handlers for authentication providers (OAuth1, OAuth2)

gologin Package gologin provides chainable login http.Handler's for Google, Github, Twitter, Facebook, Bitbucket, Tumblr, or any OAuth1 or OAuth2 auth

Dalton Hubble 1.4k Sep 23, 2021
Go OAuth2

OAuth2 for Go oauth2 package contains a client implementation for OAuth 2.0 spec. Installation go get golang.org/x/oauth2 Or you can manually git clo

Go 3.8k Sep 25, 2021
A collection of authentication Go packages related to OIDC, JWKs and Distributed Claims.

cap (collection of authentication packages) provides a collection of related packages which enable support for OIDC, JWT Verification and Distributed Claims.

HashiCorp 297 Sep 19, 2021
Platform-Agnostic Security Tokens implementation in GO (Golang)

Golang implementation of PASETO: Platform-Agnostic Security Tokens This is a 100% compatible pure Go (Golang) implementation of PASETO tokens. PASETO

Oleg Lobanov 538 Sep 20, 2021
GLAuth 1.1k Sep 25, 2021
Simple JWT Golang

sjwt Simple JSON Web Token - Uses HMAC SHA-256 Example // Set Claims claims := New() claims.Set("username", "billymister") claims.Set("account_id", 86

Brian Voelker 93 Aug 25, 2021