A go implementation of JSON Web Tokens

Related tags

go golang jwt auth


build Go Reference

A go (or 'golang' for search engine friendliness) implementation of JSON Web Tokens

NEW VERSION COMING: There have been a lot of improvements suggested since the version 3.0.0 released in 2016. I'm working now on cutting two different releases: 3.2.0 will contain any non-breaking changes or enhancements. 4.0.0 will follow shortly which will include breaking changes. See the 4.0.0 milestone to get an idea of what's coming. If you have other ideas, or would like to participate in 4.0.0, now's the time. If you depend on this library and don't want to be interrupted, I recommend you use your dependency mangement tool to pin to version 3.

SECURITY NOTICE: Some older versions of Go have a security issue in the crypto/elliptic. Recommendation is to upgrade to at least 1.8.3. See issue #216 for more detail.

SECURITY NOTICE: It's important that you validate the alg presented is what you expect. This library attempts to make it easy to do the right thing by requiring key types match the expected alg, but you should take the extra step to verify it in your usage. See the examples provided.

What the heck is a JWT?

JWT.io has a great introduction to JSON Web Tokens.

In short, it's a signed JSON object that does something useful (for example, authentication). It's commonly used for Bearer tokens in Oauth 2. A token is made of three parts, separated by .'s. The first two parts are JSON objects, that have been base64url encoded. The last part is the signature, encoded the same way.

The first part is called the header. It contains the necessary information for verifying the last part, the signature. For example, which encryption method was used for signing and what key was used.

The part in the middle is the interesting bit. It's called the Claims and contains the actual stuff you care about. Refer to RFC 7519 for information about reserved keys and the proper way to add your own.

What's in the box?

This library supports the parsing and verification as well as the generation and signing of JWTs. Current supported signing algorithms are HMAC SHA, RSA, RSA-PSS, and ECDSA, though hooks are present for adding your own.


See the project documentation for examples of usage:


This library publishes all the necessary components for adding your own signing methods. Simply implement the SigningMethod interface and register a factory method using RegisterSigningMethod.

Here's an example of an extension that integrates with multiple Google Cloud Platform signing tools (AppEngine, IAM API, Cloud KMS): https://github.com/someone1/gcp-jwt-go


This library was last reviewed to comply with RTF 7519 dated May 2015 with a few notable differences:

  • In order to protect against accidental use of Unsecured JWTs, tokens using alg=none will only be accepted if the constant jwt.UnsafeAllowNoneSignatureType is provided as the key.

Project Status & Versioning

This library is considered production ready. Feedback and feature requests are appreciated. The API should be considered stable. There should be very few backwards-incompatible changes outside of major version updates (and only with good reason).

This project uses Semantic Versioning 2.0.0. Accepted pull requests will land on main. Periodically, versions will be tagged from main. You can find all the releases on the project releases page.

While we try to make it obvious when we make breaking changes, there isn't a great mechanism for pushing announcements out to users. You may want to use this alternative package include: gopkg.in/golang-jwt/jwt.v3. It will do the right thing WRT semantic versioning.


  • Version 3.0.0 includes a lot of changes from the 2.x line, including a few that break the API. We've tried to break as few things as possible, so there should just be a few type signature changes. A full list of breaking changes is available in VERSION_HISTORY.md. See MIGRATION_GUIDE.md for more information on updating your code.

Usage Tips

Signing vs Encryption

A token is simply a JSON object that is signed by its author. this tells you exactly two things about the data:

  • The author of the token was in the possession of the signing secret
  • The data has not been modified since it was signed

It's important to know that JWT does not provide encryption, which means anyone who has access to the token can read its contents. If you need to protect (encrypt) the data, there is a companion spec, JWE, that provides this functionality. JWE is currently outside the scope of this library.

Choosing a Signing Method

There are several signing methods available, and you should probably take the time to learn about the various options before choosing one. The principal design decision is most likely going to be symmetric vs asymmetric.

Symmetric signing methods, such as HSA, use only a single secret. This is probably the simplest signing method to use since any []byte can be used as a valid secret. They are also slightly computationally faster to use, though this rarely is enough to matter. Symmetric signing methods work the best when both producers and consumers of tokens are trusted, or even the same system. Since the same secret is used to both sign and validate tokens, you can't easily distribute the key for validation.

Asymmetric signing methods, such as RSA, use different keys for signing and verifying tokens. This makes it possible to produce tokens with a private key, and allow any consumer to access the public key for verification.

Signing Methods and Key Types

Each signing method expects a different object type for its signing keys. See the package documentation for details. Here are the most common ones:

  • The HMAC signing method (HS256,HS384,HS512) expect []byte values for signing and validation
  • The RSA signing method (RS256,RS384,RS512) expect *rsa.PrivateKey for signing and *rsa.PublicKey for validation
  • The ECDSA signing method (ES256,ES384,ES512) expect *ecdsa.PrivateKey for signing and *ecdsa.PublicKey for validation

JWT and OAuth

It's worth mentioning that OAuth and JWT are not the same thing. A JWT token is simply a signed JSON object. It can be used anywhere such a thing is useful. There is some confusion, though, as JWT is the most common type of bearer token used in OAuth2 authentication.

Without going too far down the rabbit hole, here's a description of the interaction of these technologies:

  • OAuth is a protocol for allowing an identity provider to be separate from the service a user is logging in to. For example, whenever you use Facebook to log into a different service (Yelp, Spotify, etc), you are using OAuth.
  • OAuth defines several options for passing around authentication data. One popular method is called a "bearer token". A bearer token is simply a string that should only be held by an authenticated user. Thus, simply presenting this token proves your identity. You can probably derive from here why a JWT might make a good bearer token.
  • Because bearer tokens are used for authentication, it's important they're kept secret. This is why transactions that use bearer tokens typically happen over SSL.


This library uses descriptive error messages whenever possible. If you are not getting the expected result, have a look at the errors. The most common place people get stuck is providing the correct type of key to the parser. See the above section on signing methods and key types.


Documentation can be found on pkg.go.dev.

The command line utility included in this project (cmd/jwt) provides a straightforward example of token creation and parsing as well as a useful tool for debugging your own integration. You'll also find several implementation examples in the documentation.

  • Backwards-compatible implementation of RFC7519's registered claim's structure

    Backwards-compatible implementation of RFC7519's registered claim's structure

    This PR aims at implementing compliance to RFC7519, as documented in #11 without breaking the public API. It creates a new struct RegisteredClaims and deprecates (but not removes) the StandardClaims. It introduces a new type NumericDate, which represents a JSON numeric date value as specified in the RFC. This allows us to handle float as well as int-based time fields in aud, exp and nbf. Additionally, it introduces the type StringArray, which is basically a wrapper around []string to deal with the oddities of the JWT aud field.

    Closes #11

    opened by oxisto 28
  • Placeholder repo migrating maintenance

    Placeholder repo migrating maintenance

    See https://github.com/dgrijalva/jwt-go/issues/462 for a lengthier discussion and background.

    For brevity, there is/was an attempt to migrate to the gors organization, issues here, but unfortunately there was no response on GitHub issue or Slack #gofrs channel.

    Hopefully other can chip in, but afaics the goal of this org/repo:

    1. patch any outstanding security issues
    2. add module support
    3. maintain the existing jwt-go API in its current form
    4. setup GitHub Actions as CI for existing tests
    5. have a few independent maintainers to spread the load and trust of maintenance with the ultimate goal of the Go community having access to a stable JWT package.

    The intention is to support the package in its current form without any major re-write or refactor.

    I still hope one day the Go standard library or /x will add JWT support and backing from the Go team.

    If there is agreement we can setup independent GitHub issues to tackle the above and address these in particular.

    https://github.com/dgrijalva/jwt-go/issues/428 https://github.com/dgrijalva/jwt-go/issues/463

    cc @ripienaar @Waterdrips @lggomez

    opened by mfridman 17
  • Address cached references to old versions in the Go module proxy

    Address cached references to old versions in the Go module proxy

    Unfortunately the Go module proxy (i.e., mirror) cached 2 versions:


    When a user does a go get github.com/golang-jwt/jwt it will download the following version:

    github.com/golang-jwt/jwt v3.2.0+incompatible // indirect

    Whereas it should import the correct one (based on latest commit on main)

    github.com/golang-jwt/jwt v0.0.0-20210529012641-6a07921e6808 // indirect

    If we cannot get those 2 versions removed from the proxy, we'll have to go with plan B... add a /v3 and tag a v3.2.1

    opened by mfridman 17
  • Adds go module support /v4

    Adds go module support /v4

    Introduces modules support with with/v4 SIV

    • [x] Update migration guide
    • [x] Update README to ensure import paths are correct referenced

    fixes #5 #3 #30

    opened by mfridman 12
  • Due to the use of fillBytes golang-jwt now requires go1.15

    Due to the use of fillBytes golang-jwt now requires go1.15


    from #33, means that golang-jwt/jwt now requires go1.15.

    Is this intentional?

    opened by zeripath 12
  • upstream fix for security vulnerability from form3tech-oss/jwt-go fork

    upstream fix for security vulnerability from form3tech-oss/jwt-go fork

    This forwards the changes of https://github.com/form3tech-oss/jwt-go/pull/14 to the upstream repository.

    I am not the author of the original PR (nor do I know much about JWT), but thought I'd give this an attempt, following the discussion in https://github.com/Azure/go-autorest/issues/642 (and issues linked from there).

    Fixes a security vulnerability where a jwt token could potentially be validated having invalid string characters.

    (cherry picked from commit a211650c6ae1cff6d7347d3e24070d65dcfb1122) https://github.com/form3tech-oss/jwt-go/pull/14

    opened by thaJeztah 10
  • Add go module support

    Add go module support

    The existing project https://github.com/dgrijalva/jwt-go had no module support and was likely imported as:

    github.com/dgrijalva/jwt-go v3.2.0+incompatible

    There was also a v4 that never got fully released.

    go get github.com/dgrijalva/[email protected]
    go get: github.com/dgrijalva/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v4

    Since users would import a new module anyways, one solution could be drop all existing versions (14 total) and start with a fresh v1.0.0 (hopefully no breaking changes required).

    For many of my projects I see this being a basic search/replace operation:

    - github.com/dgrijalva/jwt-go v3.2.0+incompatible
    + github.com/golang-jwt/jwt v1.0.0

    The version in this case is irrelevant afaics.

    Lastly, I am not sure whether the original repo will get "transferred" or "archived" (see comment here), but if it gets transferred then this might change the outcome of how to proceed adding module support?

    Thoughts, suggestions welcome.

    opened by mfridman 10
  • Add GitHub Actions for CI

    Add GitHub Actions for CI

    GitHub Actions probably makes the most sense for OSS projects like this to avoid another dependency on external services.

    Setup CI for existing tests on every push

    | STATUS | ELAPSED |               PACKAGE               | COVER | PASS | FAIL | SKIP |
    | PASS   | 0.10s   | github.com/dgrijalva/jwt-go/request | 78.4% |    4 |    0 |    0 |
    | PASS   | 0.21s   | github.com/dgrijalva/jwt-go         | 78.3% |   24 |    0 |    0 |
    | STATUS | ELAPSED |                  TEST                   | PACKAGE |
    | PASS   |    0.03 | TestECDSAVerify                         | jwt-go  |
    | PASS   |    0.01 | TestParser_Parse                        | jwt-go  |
    | PASS   |    0.01 | TestECDSASign                           | jwt-go  |
    | PASS   |    0.01 | TestRSAPSSSaltLengthCompatibility       | jwt-go  |
    | PASS   |    0.01 | TestParser_ParseUnverified              | jwt-go  |
    | PASS   |    0.00 | TestRSASign                             | jwt-go  |
    | PASS   |    0.00 | TestNoneSign                            | jwt-go  |
    | PASS   |    0.00 | TestNoneVerify                          | jwt-go  |
    | PASS   |    0.00 | TestRSAPSSVerify                        | jwt-go  |
    | PASS   |    0.00 | TestRSAPSSSign                          | jwt-go  |
    | PASS   |    0.00 | TestHMACSign                            | jwt-go  |
    | PASS   |    0.00 | TestRSAVerify                           | jwt-go  |
    | PASS   |    0.00 | TestHMACVerify                          | jwt-go  |
    | PASS   |    0.00 | TestRSAVerifyWithPreParsedPrivateKey    | jwt-go  |
    | PASS   |    0.00 | TestRSAWithPreParsedPrivateKey          | jwt-go  |
    | PASS   |    0.00 | TestRSAKeyParsing                       | jwt-go  |
    | PASS   |    0.00 | ExampleNewWithClaims_standardClaims     | jwt-go  |
    | PASS   |    0.00 | ExampleNewWithClaims_customClaimsType   | jwt-go  |
    | PASS   |    0.00 | ExampleParseWithClaims_customClaimsType | jwt-go  |
    | PASS   |    0.00 | ExampleParse_errorChecking              | jwt-go  |
    | PASS   |    0.00 | ExampleNew_hmac                         | jwt-go  |
    | PASS   |    0.00 | ExampleParse_hmac                       | jwt-go  |
    | PASS   |    0.00 | Example_getTokenViaHTTP                 | jwt-go  |
    | PASS   |    0.00 | Example_useTokenViaHTTP                 | jwt-go  |
    |        |         |                                         |         |
    | PASS   |    0.01 | TestParseRequest                        | request |
    | PASS   |    0.00 | TestExtractor                           | request |
    | PASS   |    0.00 | ExampleHeaderExtractor                  | request |
    | PASS   |    0.00 | ExampleArgumentExtractor                | request |
    opened by mfridman 9
  • Handling and migration of original project issues

    Handling and migration of original project issues

    Closely related but now exactly the same as #7. We should triage and migrate the issues from the original repo to this one

    We could either:

    • Perform a triage there and only migrate the actionables manually (we're talking about 90 issues as of today)
    • Use some automated tool (TBD) and perform triage here
    opened by lggomez 6
  • fix!: NumericDate parsing conformance

    fix!: NumericDate parsing conformance

    The current implementation of the standard claims parser is invalid. It doesn't allow NumericDate value to be floats, while it's explicitly allowed by the RFC:

    NumericDate A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

    (Emphasis mine).

    This is annoying because popular libraries generate tokens containing floats in the exp, iat and nbf fields. For instance, it's the case of lcobucci/jwt, one of the most popular JWT library written in PHP.

    This PR fixes this, and also allows comparing fractions of seconds.

    This is a BC break, so it should be merged in the 4.0 version.

    Also, as this library is a core dependency of my Mercure project, if you need help for the maintenance of this library, I'll be glad to participate!

    Closes https://github.com/dunglas/mercure/issues/404 and https://github.com/form3tech-oss/jwt-go/pull/11.

    opened by dunglas 6
  • fix link

    fix link


    opened by greut 0
  • Create codeql-analysis.yml

    Create codeql-analysis.yml

    This adds code scanning to find security vulnerabilities.

    opened by mfridman 1
  • Refactors errors to use go 1.13 style

    Refactors errors to use go 1.13 style

    This isn't done as the tests haven't been verified but this moves errors to go 1.13. I can finish it but I don't want to burn a lot of time if you aren't interested in the changes.

    There may be too many errors, especially around signing methods, but maybe not. It definitely helps to be able to narrow down what the problem is.

    This pull request also:

    • adds accessors to MapClaims
    • changes the way signing methods are accessed. I changed the RWMutex guarding the global map of signingMethods to a Mutex. It is only locked when RegisterSigningMethod is called. The signingMethods map is then copied, modified, and then assigned over the existing map. Doing so removes the need to have a mutex checks on reads.
    opened by chanced 2
  • Token used before issued

    Token used before issued

    Having switched from github.com/dgrijalva/jwt-go to github.com/golang-jwt/jwt/v4 I still get token used before issued errors due to clock skew, even though @dgrijalva said this check would be removed from v4, in line with jwt spec. See https://github.com/golang-jwt/jwt/blob/3f50a786ff28f918ba8e7fb9183390b11483e755/claims.go#L63-L66

    However I see that check is still executed at https://github.com/dgrijalva/jwt-go/issues/314#issuecomment-481789374. Is this dependent on https://github.com/golang-jwt/jwt/issues/16 getting resolved? Until that's resolved can the VerifyIssuedAt check just be dropped? Or any other suggested workarounds?

    opened by JorritSalverda 2
  • Add `GetSigningMethods` function

    Add `GetSigningMethods` function

    opened by wisdommatt 0
  • Tests: Consider using testify require/assert for tests

    Tests: Consider using testify require/assert for tests

    The package has a policy of not depending on third party packages and consuming only the standard library but for well structured tests we could benefit from using a more sophisticated package like https://github.com/stretchr/testify, simplifying the test code and hardening the assertions

    By well structured tests, I mean tests that are in their explicit test packages, thus not being linked on build time to the non-test code (that is, is foo_test being the test package given the package foo)

    opened by lggomez 3
  • Add go fmt check on github actions

    Add go fmt check on github actions

    We have to see what are the available options on formatting, we could either perform an automatic format step upon merge (https://github.com/golang-jwt/jwt/pull/53#issuecomment-892274167) or either add/configure a linter rule for formatting

    opened by lggomez 0
  • Handling malformed JWT (includes padding)

    Handling malformed JWT (includes padding)

    I'm trying to integrate with Amazon Cognito behind an AWS load balancer. Cognito supplies a JWT, but the token includes padding. Yes, this makes it a malformed token, but it's not a token which I can change. (Specifically, when running behind an Application Load Balancer, I need to validate the x-amzn-oidc-data header. Infuriatingly, they also provide a second JWT, which is not malformed, but doesn't include some specific details which I need...)

    v3.2.2 included PR#33, which changes how the library handles this situation. Prior to the change, the Base64 text was correctly parsed, as the decoded expected padding (and this was added if it was missing). Now, the base64 parser returns an error ("illegal base64 data").

    Stripping the padding before passing to the library allows the base64 deserialisation to succeed, but the signature then fails to validate.

    Currently my only option (other than looking for a different library) seems to be to stick to v3.2.1... Any other suggestions would be very welcome!

    opened by boneheaded-bat 4
  • Add to awesome-go & misc

    Add to awesome-go & misc

    I opened https://github.com/avelino/awesome-go/pull/3695 to add this package to the list. @mfridman I requested you org access to coveralls, since it's one of the requirements (and it doesn't hurt to have a code coverage badge I guess)

    If there are other lists or sites in which we should make a contribution adding the package (like #65) it'd be worth to mention them here

    opened by lggomez 3
  • When exp indicates the present, make it invalid.

    When exp indicates the present, make it invalid.


    The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing.

    it is written on the reference. So, it seems invalid when exp indicates the present. Isn't it right?

    opened by soranoba 6
  • v4.0.0(Aug 3, 2021)

    • Adds Go module support (#41). You can import this package using the following import path:

    This release, and any future /v4 work is intended to be backwards-compatible with existing v3.x.y tags.

    See the migration guide for more details.

    Source code(tar.gz)
    Source code(zip)
  • v3.2.2(Jul 30, 2021)

    • Starting from this release, we are adopting the policy to support the most 2 recent versions of Go currently available. By the time of this release, this is Go 1.15 and 1.16 (#28).
    • Fixed a potential issue that could occur when the presence of exp, iat or nbf was not required for verification and contained invalid contents, i.e. non-numeric/date. Thanks for @thaJeztah for making us aware of that and @giorgos-f3 for originally reporting it to the formtech fork (#40).
    • Added support for EdDSA / ED25519 (#36).
    • Optimized allocations (#33).
    Source code(tar.gz)
    Source code(zip)
  • v3.2.1(Jun 8, 2021)

    • Import Path Change: See MIGRATION_GUIDE.md for tips on updating your code
      • Changed the import path from github.com/dgrijalva/jwt-go to github.com/golang-jwt/jwt
    • Fixed type confusion issue between string and []string in VerifyAudience (#12). This fixes CVE-2020-26160
    Source code(tar.gz)
    Source code(zip)
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 14, 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 6, 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 866 Sep 13, 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 2, 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 535 Sep 1, 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 263 Aug 25, 2021
⛩️ Go library for protecting HTTP handlers with authorization bearer token.

G8, pronounced Gate, is a simple Go library for protecting HTTP handlers with tokens. Tired of constantly re-implementing a security layer for each

Chris C. 28 Aug 6, 2021
vault-plugin-auth-usertotp is an auth method plugin for HashiCorp Vault

vault-plugin-auth-usertotp is an auth method plugin for HashiCorp Vault. Create user accounts, add TOTP tokens (user supplied pin + totp), and have peace of mind using 2FA.

Mike McRill 6 Jul 5, 2021
JWT login microservice with plugable backends such as OAuth2, Google, Github, htpasswd, osiam, ..

loginsrv loginsrv is a standalone minimalistic login server providing a JWT login for multiple login backends. ** Attention: Update to v1.3.0 for Goog

tarent 1.8k Sep 13, 2021
An implementation of JOSE standards (JWE, JWS, JWT) in Go

Go JOSE Package jose aims to provide an implementation of the Javascript Object Signing and Encryption set of standards. This includes support for JSO

Square 1.8k Sep 8, 2021
Certificate authority and access plane for SSH, Kubernetes, web applications, and databases

Teleport is an identity-aware, multi-protocol access proxy which understands SSH, HTTPS, Kubernetes API, MySQL and PostgreSQL wire protocols.

Teleport 10k Sep 15, 2021
Go + Vue开发的管理系统脚手架, 前后端分离, 仅包含项目开发的必需部分, 基于角色的访问控制(RBAC), 分包合理, 精简易于扩展。 后端Go包含了gin、 gorm、 jwt和casbin等的使用, 前端Vue基于vue-element-admin开发

go-web-mini Go + Vue开发的管理系统脚手架, 前后端分离, 仅包含项目开发的必需部分, 基于角色的访问控制(RBAC), 分包合理, 精简易于扩展。 后端Go包含了gin、 gorm、 jwt和casbin等的使用, 前端Vue基于vue-element-admin开发: http

gnimli 17 Sep 9, 2021
Small Lambda function which performs a Aws:Sts:AssumeRole based on the presented JWT-Token

About This implements a AWS Lambda handler which takes a JWT-Token, validates it and then performs a Aws:Sts:AssumeRole based on preconfigured rules.

AOE 4 Aug 25, 2021
Time-Based One-Time Password (TOTP) and HMAC-Based One-Time Password (HOTP) library for Go.

otpgo HMAC-Based and Time-Based One-Time Password (HOTP and TOTP) library for Go. Implements RFC 4226 and RFC 6238. Contents Supported Operations Read

Jose Torres 23 Aug 27, 2021
GLAuth 1.1k Sep 12, 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 dead simple, highly performant, highly customizable sessions middleware for go http servers.

If you're interested in jwt's, see my jwt library! Sessions A dead simple, highly performant, highly customizable sessions service for go http servers

Adam Hanna 60 Jul 3, 2021
Casdoor is a UI-first centralized authentication / Single-Sign-On (SSO) platform based on OAuth 2.0 / OIDC.

A UI-first centralized authentication / Single-Sign-On (SSO) platform based on OAuth 2.0 / OIDC

Casbin 344 Sep 7, 2021
Herbert Fischer 193 Sep 2, 2021