Dropwizard Jwt Cookie Authentication

Dropwizard bundle managing authentication through JWT cookies
Alternatives To Dropwizard Jwt Cookie Authentication
Project NameStarsDownloadsRepos Using ThisPackages Using ThisMost Recent CommitTotal ReleasesLatest ReleaseOpen IssuesLicenseLanguage
3 days ago35apache-2.0Java
mall项目是一套电商系统,包括前台商城系统及后台管理系统,基于SpringBoot+MyBatis实现,采用Docker容器化部署。 前台商城系统包含首页门户、商品推荐、商品搜索、商品展示、购物车、订单流程、会员中心、客户服务、帮助中心等模块。 后台管理系统包含商品管理、订单管理、会员管理、促销管理、运营管理、内容管理、统计报表、财务管理、权限管理、设置等模块。
Next Auth16,95521734 hours ago567August 01, 2022241iscTypeScript
Authentication for the Web.
Auth Boss2,843
6 years ago
🔒 Become an Auth Boss. Learn about different authentication methodologies on the web.
Vouch Proxy2,289
a month ago157August 12, 202257mitGo
an SSO and OAuth / OIDC login solution for Nginx using the auth_request module
7 days ago5mitC#
Todo application with ASP.NET Core Blazor WASM, Minimal APIs and Authentication
Auth Module1,864139323 days ago51April 16, 2020198mitTypeScript
Zero-boilerplate authentication support for Nuxt.js!
22 years ago7February 11, 202127mitGo
JWT login microservice with plugable backends such as OAuth2, Google, Github, htpasswd, osiam, ..
a month ago29apache-2.0Java
HIS英文全称 hospital information system(医疗信息就诊系统),系统主要功能按照数据流量、流向及处理过程分为临床诊疗、药品管理、财务管理、患者管理。诊疗活动由各工作站配合完成,并将临床信息进行整理、处理、汇总、统计、分析等。本系统包括以下工作站:门诊医生工作站、药房医生工作站、医技医生工作站、收费员工作站、对帐员工作站、管理员工作站。需求为东软提供的云医院。
Fastify Jwt380455812 days ago47April 27, 20224mitJavaScript
JWT utils for Fastify
Supra Api Nodejs294
4 months ago7mitJavaScript
❤️ Node.js REST API boilerplate
Alternatives To Dropwizard Jwt Cookie Authentication
Select To Compare

Alternative Project Comparisons

Build Status Maven Central Coverage Status Javadoc Mentioned in Awesome Dropwizard

Please note version 4 requires Dropwizard 2.


Statelessness is not only an architectural constaint of RESTful applications, it also comes with a lot of advantages regarding scalability and memory usage.

A common pattern is to provide the client with a signed JWT containing all necessary authorization and/or session state information. This JWT must then be passed along subsequent requests, usually in bearer Authorization HTTP headers.

However, in the particular case where clients of the RESTful application are web applications, it is much more interesting to use cookies. The browser will automatically read, store, send and expire the tokens, saving front-end developers the hassle of doing it themselves.

This dropwizard bundle makes things simple for back-end developpers too. It automatically serializes/deserializes session information into/from JWT cookies.

Enabling the bundle

Add the dropwizard-jwt-cookie-authentication dependency

Add the dropwizard-jwt-cookie-authentication library as a dependency to your pom.xml file:


Edit you app's Dropwizard YAML config file

The default values are shown below. If they suit you, this step is optional.

  secretSeed: null
  secure: false
  httpOnly: true
  domain: null
  sameSite: null
  sessionExpiryVolatile: PT30m
  sessionExpiryPersistent: P7d

Add the 'JwtCookieAuthConfiguration' to your application configuration class:

This step is also optional if you skipped the previous one.

private JwtCookieAuthConfiguration jwtCookieAuth = new JwtCookieAuthConfiguration();

public JwtCookieAuthConfiguration getJwtCookieAuth() {
  return jwtCookieAuth;

Add the bundle to the dropwizard application

public void initialize(Bootstrap<MyApplicationConfiguration> bootstrap) {

If you have a custom configuration fot the bundle, specify it like so:


Using the bundle

By default, the JWT cookie is serialized from / deserialized in an instance of DefaultJwtCookiePrincipal.

When the user authenticate, you must put an instance of DefaultJwtCookiePrincipal in the security context (which you can inject in your resources using the @Context annotation) using JwtCookiePrincipal.addInContext

JwtCookiePrincipal principal = new DefaultJwtCookiePrincipal(name);

Once a principal has been set, it can be retrieved using the @Auth annotation in method signatures. You can also use CurrentPrincipal.get() within the request thread.

Each time an API endpoint is called, a fresh cookie JWT is issued to reset the session TTL. You can use the @DontRefreshSession on methods where this behavior is unwanted.

To specify a max age in the cookie (aka "remember me"), use DefaultJwtCookiePrincipal.setPersistent(true).

It is a stateless auhtentication method, so there is no real way to invalidate a session other than waiting for the JWT to expire. However calling JwtCookiePrincipal.removeFromContext(context) will make browsers discard the cookie by setting the cookie expiration to a past date.

Principal roles can be specified via the DefaultJwtCookiePrincipal.setRoles(...) method. You can then define fine grained access control using annotations such as @RolesAllowed or @PermitAll.

Additional custom data can be stored in the Principal using DefaultJwtCookiePrincipal.getClaims().put(key, value).

Sample application resource

public DefaultJwtCookiePrincipal login(@Context ContainerRequestContext requestContext, String name){
    DefaultJwtCookiePrincipal principal = new DefaultJwtCookiePrincipal(name);
    return principal;

public void logout(@Context ContainerRequestContext requestContext){

public DefaultJwtCookiePrincipal getPrincipal(@Auth DefaultJwtCookiePrincipal principal){
    return principal;

public DefaultJwtCookiePrincipal getSubjectWithoutRefreshingSession(@Auth DefaultJwtCookiePrincipal principal){
    return principal;

public String getRestrictedResource(){
    return "SuperSecretStuff";

Custom principal implementation

If you want to use your own Principal class instead of the DefaultJwtCookiePrincipal, simply implement the interface JwtCookiePrincipal and pass it to the bundle constructor along with functions to serialize it into / deserialize it from JWT claims.


bootstrap.addBundle(new JwtCookieAuthBundle<>(MyCustomPrincipal.class, MyCustomPrincipal::toClaims, MyCustomPrincipal::new));

JWT Signing Key

By default, the signing key is randomly generated on application startup. It means that users will have to re-authenticate after each server reboot.

To avoid this, you can specify a secretSeed in the configuration. This seed will be used to generate the signing key, which will therefore be the same at each application startup.

Alternatively you can specify your own key factory:

bootstrap.addBundle(JwtCookieAuthBundle.getDefault().withKeyProvider((configuration, environment) -> {/*return your own key*/}));

Manual Setup

If you need Chained Factories or Multiple Principals and Authenticators, don't register directly the bundle. Use instead its getAuthRequestFilter and getAuthResponseFilter methods to manually setup authentication.

You will also be responsible for generating the signing key and registering RolesAllowedDynamicFeature or DontRefreshSessionFilter if they are needed.


JwtCookieAuthBundle jwtCookieAuthBundle = new JwtCookieAuthBundle<>(

Key key = JwtCookieAuthBundle.generateKey(configuration.getJwtCookieAuth().getSecretSeed());

        new PolymorphicAuthDynamicFeature<>(
                        MyJwtCookiePrincipal.class, jwtCookieAuthBundle.getAuthRequestFilter(key),
                        MyBasicPrincipal.class, new BasicCredentialAuthFilter.Builder<MyBasicPrincipal>()
                            .setAuthenticator(new MyBasicAuthenticator())
                            .setRealm("SUPER SECRET STUFF")
environment.jersey().register(new PolymorphicAuthValueFactoryProvider.Binder<>(ImmutableSet.of(MyJwtCookiePrincipal.class, MyBasicPrincipal.class)));
environment.jersey().register(jwtCookieAuthBundle.getAuthResponseFilter(key, configuration.getJwtCookieAuth()));


It's here.

Popular Cookie Projects
Popular Jwt Projects
Popular Networking Categories
Related Searches

Get A Weekly Email With Trending Projects For These Categories
No Spam. Unsubscribe easily at any time.