{"id":13546044,"url":"https://github.com/waiting-for-dev/devise-jwt","last_synced_at":"2025-05-13T15:11:03.139Z","repository":{"id":40629850,"uuid":"78737622","full_name":"waiting-for-dev/devise-jwt","owner":"waiting-for-dev","description":"JWT token authentication with devise and rails","archived":false,"fork":false,"pushed_at":"2025-05-09T10:51:38.000Z","size":294,"stargazers_count":1273,"open_issues_count":5,"forks_count":129,"subscribers_count":16,"default_branch":"main","last_synced_at":"2025-05-09T11:55:23.350Z","etag":null,"topics":["authentication","devise","jwt","rails","ruby-gem"],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/waiting-for-dev.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE.txt","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"github":"waiting-for-dev"}},"created_at":"2017-01-12T11:13:34.000Z","updated_at":"2025-05-09T10:51:42.000Z","dependencies_parsed_at":"2024-09-30T15:00:57.155Z","dependency_job_id":"166c8e5d-eef7-4697-a845-0c95a5040b17","html_url":"https://github.com/waiting-for-dev/devise-jwt","commit_stats":{"total_commits":236,"total_committers":38,"mean_commits":"6.2105263157894735","dds":0.2542372881355932,"last_synced_commit":"3a0ade4bdcc9e23ff407f157ea59863da8b12279"},"previous_names":[],"tags_count":24,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waiting-for-dev%2Fdevise-jwt","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waiting-for-dev%2Fdevise-jwt/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waiting-for-dev%2Fdevise-jwt/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/waiting-for-dev%2Fdevise-jwt/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/waiting-for-dev","download_url":"https://codeload.github.com/waiting-for-dev/devise-jwt/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253969249,"owners_count":21992263,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["authentication","devise","jwt","rails","ruby-gem"],"created_at":"2024-08-01T12:00:30.513Z","updated_at":"2025-05-13T15:10:58.127Z","avatar_url":"https://github.com/waiting-for-dev.png","language":"Ruby","readme":"# Devise::JWT\n\n[![Gem Version](https://badge.fury.io/rb/devise-jwt.svg)](https://badge.fury.io/rb/devise-jwt)\n[![Build Status](https://travis-ci.org/waiting-for-dev/devise-jwt.svg?branch=master)](https://travis-ci.org/waiting-for-dev/devise-jwt)\n[![Code Climate](https://codeclimate.com/github/waiting-for-dev/devise-jwt/badges/gpa.svg)](https://codeclimate.com/github/waiting-for-dev/devise-jwt)\n[![Test Coverage](https://codeclimate.com/github/waiting-for-dev/devise-jwt/badges/coverage.svg)](https://codeclimate.com/github/waiting-for-dev/devise-jwt/coverage)\n\n`devise-jwt` is a [Devise](https://github.com/plataformatec/devise) extension which uses [JWT](https://jwt.io/) tokens for user authentication. It follows [secure by default](https://en.wikipedia.org/wiki/Secure_by_default) principle.\n\nThis gem is just a replacement for cookies when these can't be used. As with\ncookies, a `devise-jwt` token will mandatorily have an expiration\ntime. If you need that your users never sign out, you will be better off with a\nsolution using refresh tokens, like some implementation of OAuth2.\n\nYou can read about which security concerns this library takes into account and about JWT generic secure usage in the following series of posts:\n\n- [Stand Up for JWT Revocation](http://waiting-for-dev.github.io/blog/2017/01/23/stand_up_for_jwt_revocation)\n- [JWT Revocation Strategies](http://waiting-for-dev.github.io/blog/2017/01/24/jwt_revocation_strategies)\n- [JWT Secure Usage](http://waiting-for-dev.github.io/blog/2017/01/25/jwt_secure_usage)\n- [A secure JWT authentication implementation for Rack and Rails](http://waiting-for-dev.github.io/blog/2017/01/26/a_secure_jwt_authentication_implementation_for_rack_and_rails)\n\n`devise-jwt` is just a thin layer on top of [`warden-jwt_auth`](https://github.com/waiting-for-dev/warden-jwt_auth) that configures it to be used out of the box with Devise and Rails.\n\n## Upgrade notes\n\n### v0.7.0\n\nSince version v0.7.0 `Blacklist` revocation strategy has been renamed to `Denylist` while `Whitelist` has been renamed to `Allowlist`.\n\nFor `Denylist`, you only need to update the `include` line you're using in your revocation strategy model:\n\n```ruby\n# include Devise::JWT::RevocationStrategies::Blacklist # before\ninclude Devise::JWT::RevocationStrategies::Denylist\n```\n\nFor `Allowlist`, you need to update the `include` line you're using in your user model:\n\n```ruby\n# include Devise::JWT::RevocationStrategies::Whitelist # before\ninclude Devise::JWT::RevocationStrategies::Allowlist\n```\n\nYou also have to rename your `WhitelistedJwt` model to `AllowlistedJwt`, rename `model/whitelisted_jwt.rb` to `model/allowlisted_jwt.rb` and change the underlying database table to `allowlisted_jwts` (or configure the model to keep using the old name).\n\n## Installation\n\nAdd this line to your application's Gemfile:\n\n```ruby\ngem 'devise-jwt'\n```\n\nAnd then execute:\n\n    $ bundle\n\nOr install it yourself as:\n\n    $ gem install devise-jwt\n\n## Usage\n\nFirst, you need to configure Devise to work in an API application. You can follow the instructions in this project wiki page [Configuring Devise for APIs](https://github.com/waiting-for-dev/devise-jwt/wiki/Configuring-devise-for-APIs) (you are more than welcome to improve them).\n\n### Secret key configuration\n\nYou have to configure the secret key that will be used to sign generated tokens. You can do it in the Devise initializer:\n\n```ruby\nDevise.setup do |config|\n  # ...\n  config.jwt do |jwt|\n    jwt.secret = ENV['DEVISE_JWT_SECRET_KEY']\n  end\nend\n```\n\nIf you are using Encrypted Credentials (Rails 5.2+), you can store the secret key in `config/credentials.yml.enc`.\n\nOpen your credentials editor using `bin/rails credentials:edit` and add `devise_jwt_secret_key`.\n\n\u003e **Note** you may need to set `$EDITOR` depending on your specific environment.\n\n```yml\n\n# Other secrets...\n\n# Used as the base secret for Devise JWT\ndevise_jwt_secret_key: abc...xyz\n```\n\nAdd the following to the Devise initializer.\n\n```ruby\nDevise.setup do |config|\n  # ...\n  config.jwt do |jwt|\n    jwt.secret = Rails.application.credentials.devise_jwt_secret_key!\n  end\nend\n```\n\n\u003e **Important:** You are encouraged to use a secret different than your application `secret_key_base`. It is quite possible that some other component of your system is already using it. If several components share the same secret key, chances that a vulnerability in one of them has a wider impact increase. In rails, generating new secrets is as easy as `rails secret`. Also, never share your secrets pushing it to a remote repository, you are better off using an environment variable like in the example.\n\nCurrently, HS256 algorithm is the one in use. You may configure a matching secret and algorithm name to use a different one (see [ruby-jwt](https://github.com/jwt/ruby-jwt#algorithms-and-usage) to see which are supported):\n\n```ruby\nDevise.setup do |config|\n  # ...\n  config.jwt do |jwt|\n    jwt.secret = OpenSSL::PKey::RSA.new(Rails.application.credentials.devise_jwt_secret_key!)\n    jwt.algorithm = Rails.application.credentials.devise_jwt_algorithm!\n  end\nend\n```\n\nIf the algorithm is asymmetric (e.g. RS256) which necessitates a different decoding secret, configure the `decoding_secret` setting as well:\n\n```ruby\nDevise.setup do |config|\n  # ...\n  config.jwt do |jwt|\n    jwt.secret = OpenSSL::PKey::RSA.new(Rails.application.credentials.devise_jwt_private_key!)\n    jwt.decoding_secret = OpenSSL::PKey::RSA.new(Rails.application.credentials.devise_jwt_public_key!)\n    jwt.algorithm = 'RS256' # or some other asymmetric algorithm\n  end\nend\n```\n\n### Model configuration\n\nYou have to tell which user models you want to be able to authenticate with JWT tokens. For them, the authentication process will be like this:\n\n- A user authenticates through Devise create session request (for example, using the standard `:database_authenticatable` module).\n- If the authentication succeeds, a JWT token is dispatched to the client in the `Authorization` response header, with format `Bearer #{token}` (tokens are also dispatched on a successful sign up).\n- The client can use this token to authenticate following requests for the same user, providing it in the `Authorization` request header, also with format `Bearer #{token}`\n- When the client visits Devise destroy session request, the token is revoked.\n\nSee [request_formats](#request_formats) configuration option if you are using paths with a format segment (like `.json`) in order to use it properly.\n\nAs you see, unlike other JWT authentication libraries, it is expected that tokens will be revoked by the server. I wrote about [why I think JWT revocation is needed and useful](http://waiting-for-dev.github.io/blog/2017/01/23/stand_up_for_jwt_revocation).\n\nAn example configuration:\n\n```ruby\nclass User \u003c ApplicationRecord\n  devise :database_authenticatable,\n         :jwt_authenticatable, jwt_revocation_strategy: Denylist\nend\n```\n\nIf you need to add something to the JWT payload, you can do it by defining a `jwt_payload` method in the user model. It must return a `Hash`. For instance:\n\n```ruby\ndef jwt_payload\n  { 'foo' =\u003e 'bar' }\nend\n```\n\nYou can add a hook method `on_jwt_dispatch` on the user model. It is executed when a token dispatched for that user instance, and it takes `token` and `payload` as parameters.\n\n```ruby\ndef on_jwt_dispatch(token, payload)\n  do_something(token, payload)\nend\n```\n\nNote: if you are making cross-domain requests, make sure that you add `Authorization` header to the list of allowed request headers and exposed response headers. You can use something like [rack-cors](https://github.com/cyu/rack-cors) for that, for example:\n\n```ruby\nconfig.middleware.insert_before 0, Rack::Cors do\n  allow do\n    origins 'http://your.frontend.domain.com'\n    resource '/api/*',\n      headers: %w(Authorization),\n      methods: :any,\n      expose: %w(Authorization),\n      max_age: 600\n  end\nend\n```\n\n#### Session storage caveat\n\nIf you are working with a Rails application that has session storage enabled\nand a default Devise setup, chances are the same origin requests will be\nauthenticated from the session regardless of a token being present in the\nheaders or not.\n\nThis is so because of the following default Devise workflow:\n\n- When a user signs in with `:database_authenticatable` strategy, the user is\n  stored in the session unless one of the following conditions is met:\n  - Session is disabled.\n  - Devise `config.skip_session_storage` includes `:params_auth`.\n  - [Rails Request forgery\n    protection](http://api.rubyonrails.org/classes/ActionController/RequestForgeryProtection.html)\n    handles an unverified request (but this is usually deactivated for API\n    requests).\n- Warden (the engine below Devise), authenticates any request that the user has\n  in the session without requiring a strategy (`:jwt_authenticatable`\n  in our case).\n\nSo, if you want to avoid this caveat you have five options:\n\n- Disable the session. If you are developing an API, you probably don't need\n  it. In order to disable it, change `config/initializers/session_store.rb` to:\n  \n  ```ruby\n  Rails.application.config.session_store :disabled\n  ```\n  Notice that if you created the application with the `--api` flag you already\n  have the session disabled.\n- If you still need the session for any other purpose, disable\n  `:database_authenticatable` user storage. In `config/initializers/devise.rb`:\n  \n  ```ruby\n  config.skip_session_storage = [:http_auth, :params_auth]\n  ```\n- If you are using Devise for another model (e.g. `AdminUser`) and doesn't want\n  to disable session storage for Devise entirely, you can disable it on a\n  per-model basis:\n  \n  ```ruby\n  class User \u003c ApplicationRecord\n    devise :database_authenticatable #, your other enabled modules...\n    self.skip_session_storage = [:http_auth, :params_auth]\n  end\n  ```\n- If you need the session for some of the controllers, you are able to disable it at\n  the controller level for those controllers which don't need it:\n  \n  ```ruby\n  class AdminsController \u003c ApplicationController\n    before_action :drop_session_cookie\n\n    private\n\n    def drop_session_cookie\n      request.session_options[:skip] = true\n    end\n  ```\n- As the last option you can tell Devise to not store the user in the Warden session\n  if you override default Devise `SessionsController` with your own one, and pass\n  `store: false` attribute to the `sign_in`, `sign_in_and_redirect`, `bypass_sign_in`\n  methods:\n  \n  ```ruby\n  sign_in user, store: false\n  ```\n\n### Revocation strategies\n\n`devise-jwt` comes with three revocation strategies out of the box. Some of them are implementations of what is discussed in the blog post [JWT Revocation Strategies](http://waiting-for-dev.github.io/blog/2017/01/24/jwt_revocation_strategies), where I also talk about their pros and cons.\n\n#### JTIMatcher\n\nHere, the model class acts as the revocation strategy. It needs a new string column named `jti` to be added to the user. `jti` stands for JWT ID, and it is a standard claim meant to uniquely identify a token.\n\nIt works like the following:\n\n- When a token is dispatched for a user, the `jti` claim is taken from the `jti` column in the model (which has been initialized when the record has been created).\n- At every authenticated action, the incoming token `jti` claim is matched against the `jti` column for that user. The authentication only succeeds if they are the same.\n- When the user requests to sign out its `jti` column changes, so that provided token won't be valid anymore.\n\nIn order to use it, you need to add the `jti` column to the user model. So, you have to set something like the following in a migration:\n\n```ruby\ndef change\n  add_column :users, :jti, :string, null: false\n  add_index :users, :jti, unique: true\n  # If you already have user records, you will need to initialize its `jti` column before setting it to not nullable. Your migration will look this way:\n  # add_column :users, :jti, :string\n  # User.all.each { |user| user.update_column(:jti, SecureRandom.uuid) }\n  # change_column_null :users, :jti, false\n  # add_index :users, :jti, unique: true\nend\n```\n\n**Important:** You are encouraged to set a unique index in the `jti` column. This way we can be sure at the database level that there aren't two valid tokens with same `jti` at the same time.\n\nThen, you have to add the strategy to the model class and configure it accordingly:\n\n```ruby\nclass User \u003c ApplicationRecord\n  include Devise::JWT::RevocationStrategies::JTIMatcher\n\n  devise :database_authenticatable,\n         :jwt_authenticatable, jwt_revocation_strategy: self\nend\n```\n\nBe aware that this strategy makes uses of `jwt_payload` method in the user model, so if you need to use it don't forget to call `super`:\n\n```ruby\ndef jwt_payload\n  super.merge('foo' =\u003e 'bar')\nend\n```\n\n#### Denylist\n\nIn this strategy, a database table is used as a list of revoked JWT tokens. The `jti` claim, which uniquely identifies a token, is persisted. The `exp` claim is also stored to allow the clean-up of stale tokens.\n\nIn order to use it, you need to create the denylist table in a migration:\n\n```ruby\ndef change\n  create_table :jwt_denylist do |t|\n    t.string :jti, null: false\n    t.datetime :exp, null: false\n  end\n  add_index :jwt_denylist, :jti\nend\n```\nFor performance reasons, it is better if the `jti` column is an index.\n\nNote: if you used the denylist strategy before version 0.4.0 you may not have the field *exp.* If not, run the following migration:\n\n```ruby\nclass AddExpirationTimeToJWTDenylist \u003c ActiveRecord::Migration\n  def change\n    add_column :jwt_denylist, :exp, :datetime, null: false\n  end\nend\n\n```\n\nThen, you need to create the corresponding model and include the strategy:\n\n```ruby\nclass JwtDenylist \u003c ApplicationRecord\n  include Devise::JWT::RevocationStrategies::Denylist\n\n  self.table_name = 'jwt_denylist'\nend\n```\n\nLast, configure the user model to use it:\n\n```ruby\nclass User \u003c ApplicationRecord\n  devise :database_authenticatable,\n         :jwt_authenticatable, jwt_revocation_strategy: JwtDenylist\nend\n```\n\n#### Allowlist\n\nHere, the model itself also acts as a revocation strategy, but it needs to have\na one-to-many association with another table which stores the tokens (in fact\ntheir `jti` claim, which uniquely identifies them) that are valid for each user record.\n\nThe workflow is as the following:\n\n- Once a token is dispatched for a user, its `jti` claim is stored in the\n  associated table.\n- At every authentication, the incoming token `jti` is matched against all the\n  `jti` associated to that user. The authentication only succeeds if one of\n  them matches.\n- On a sign out, the token `jti` is deleted from the associated table.\n\nIn fact, besides the `jti` claim, the `aud` claim is also stored and matched at\nevery authentication. This, together with the [aud_header](#aud_header)\nconfiguration parameter, can be used to differentiate between clients or\ndevices for the same user.\n\nThe `exp` claim is also stored to allow the clean-up of staled tokens.\n\nIn order to use it, you have to create the associated table and model.\nThe association table must be called `allowlisted_jwts`:\n\n```ruby\ndef change\n  create_table :allowlisted_jwts do |t|\n    t.string :jti, null: false\n    t.string :aud\n    # If you want to leverage the `aud` claim, add to it a `NOT NULL` constraint:\n    # t.string :aud, null: false\n    t.datetime :exp, null: false\n    t.references :your_user_table, foreign_key: { on_delete: :cascade }, null: false\n  end\n\n  add_index :allowlisted_jwts, :jti, unique: true\nend\n```\nImportant: You are encouraged to set a unique index in the `jti` column. This way we can be sure at the database level that there aren't two valid tokens with the same `jti` at the same time. Defining `foreign_key: { on_delete: :cascade }, null: false` on `t.references :your_user_table` helps to keep referential integrity of your database.\n\nAnd then, the model:\n\n```ruby\nclass AllowlistedJwt \u003c ApplicationRecord\nend\n```\n\nFinally, include the strategy in the model and configure it:\n\n```ruby\nclass User \u003c ApplicationRecord\n  include Devise::JWT::RevocationStrategies::Allowlist\n\n  devise :database_authenticatable,\n         :jwt_authenticatable, jwt_revocation_strategy: self\nend\n```\n\nBe aware that this strategy makes uses of `on_jwt_dispatch` method in the user model, so if you need to use it don't forget to call `super`:\n\n```ruby\ndef on_jwt_dispatch(token, payload)\n  super\n  do_something(token, payload)\nend\n```\n\n#### Null strategy\n\nA [null object pattern](https://en.wikipedia.org/wiki/Null_Object_pattern) strategy, which does not revoke tokens, is provided out of the box just in case you are absolutely sure you don't need token revocation. It is recommended **not to use it**.\n\n```ruby\nclass User \u003c ApplicationRecord\n  devise :database_authenticatable,\n         :jwt_authenticatable, jwt_revocation_strategy: Devise::JWT::RevocationStrategies::Null\nend\n```\n\n#### Custom strategies\n\nYou can also implement your own strategies. They just need to implement two methods: `jwt_revoked?` and `revoke_jwt`, both of them accept the JWT payload and the user record as parameters, in this order.\n\nFor instance:\n\n```ruby\nmodule MyCustomStrategy\n  def self.jwt_revoked?(payload, user)\n    # Does something to check whether the JWT token is revoked for given user\n  end\n\n  def self.revoke_jwt(payload, user)\n    # Does something to revoke the JWT token for given user\n  end\nend\n\nclass User \u003c ApplicationRecord\n  devise :database_authenticatable,\n         :jwt_authenticatable, jwt_revocation_strategy: MyCustomStrategy\nend\n```\n\n### Testing\n\nModels configured with `:jwt_authenticatable` usually won't be retrieved from\nthe session. For this reason, `sign_in` Devise testing helper methods won't\nwork as expected.\n\nWhat you need to do to authenticate test environment requests is the\nsame that you will do in production: to provide a valid token in the\n`Authorization` header (in the form of `Bearer #{token}`) at every request.\n\nThere are two ways you can get a valid token:\n\n- Inspecting the `Authorization` response header after a valid sign in request.\n- Manually creating it.\n\nThe first option tests the real workflow of your application, but it can slow\nthings if you perform it at every test.\n\nFor the second option, a test helper is provided in order to add the\n`Authorization` name/value pair to given request headers. You can use it as in\nthe following example:\n\n```ruby\n# First, require the helper module\nrequire 'devise/jwt/test_helpers'\n\n# ...\n\n  it 'tests something' do\n    user = fetch_my_user()\n    headers = { 'Accept' =\u003e 'application/json', 'Content-Type' =\u003e 'application/json' }\n    # This will add a valid token for `user` in the `Authorization` header\n    auth_headers = Devise::JWT::TestHelpers.auth_headers(headers, user)\n\n    get '/my/end_point', headers: auth_headers\n\n    expect_something()\n  end\n```\n\nUsually you will wrap this in your own test helper.\n\n### Configuration reference\n\nThis library can be configured calling `jwt` on Devise config object:\n\n```ruby\nDevise.setup do |config|\n  config.jwt do |jwt|\n    # ...\n  end\nend\n```\n#### secret\n\nSecret key is used to sign generated JWT tokens. You must set it.\n\n#### rotation_secret\n\nAllow rotating secrets. Set a new value to `secret` and copy the old secret to `rotation_secret`.\n\n#### expiration_time\n\nNumber of seconds while a JWT is valid after its generation. After that, it won't be valid anymore, even if it hasn't been revoked.\n\nDefaults to 3600 seconds (1 hour).\n\n#### dispatch_requests\n\nBesides the create session one, there are additional requests where JWT tokens should be dispatched.\n\nIt must be a bidimensional array, each item being an array of two elements: the request method and a regular expression that must match the request path.\n\nFor example:\n\n```ruby\njwt.dispatch_requests = [\n                          ['POST', %r{^/dispatch_path_1$}],\n                          ['GET', %r{^/dispatch_path_2$}],\n                        ]\n```\n\n**Important**: You are encouraged to delimit your regular expression with `^` and `$` to avoid unintentional matches.\n\n#### revocation_requests\n\nBesides the destroy session one, there are additional requests where JWT tokens should be revoked.\n\nIt must be a bidimensional array, each item being an array of two elements: the request method and a regular expression that must match the request path.\n\nFor example:\n\n```ruby\njwt.revocation_requests = [\n                            ['DELETE', %r{^/revocation_path_1$}],\n                            ['GET', %r{^/revocation_path_2$}],\n                          ]\n```\n\n**Important**: You are encouraged to delimit your regular expression with `^` and `$` to avoid unintentional matches.\n\n#### request_formats\n\nRequest formats that must be processed (in order to dispatch or revoke tokens).\n\nIt must be a hash of Devise scopes as keys and an array of request formats as\nvalues. When a scope is not present or if it has a nil item, requests without\nformat will be taken into account.\n\nFor example, with following configuration, `user` scope would dispatch and\nrevoke tokens in `json` requests (as in `/users/sign_in.json`), while\n`admin_user` would do it in `xml` and with no format (as in\n`/admin_user/sign_in.xml` and `/admin_user/sign_in`).\n\n```ruby\njwt.request_formats = {\n                        user: [:json],\n                        admin_user: [nil, :xml]\n                      }\n```\n\nBy default, only requests without format are processed.\n\n#### token_header\n\nRequest/response header which will transmit the JWT token.\n\nDefaults to 'Authorization'\n\n#### issuer\n\nExpected issuer claim. If present, it will be checked against the incoming\ntoken issuer claim and authorization will be skipped if they don't match.\n\nDefaults to nil.\n\n#### aud_header\n\nRequest header which content will be stored to the `aud` claim in the payload.\n\nIt is used to validate whether an incoming token was originally issued to the\nsame client, checking if `aud` and the `aud_header` header value match. If you\ndon't want to differentiate between clients, you don't need to provide that\nheader.\n\n**Important:** Be aware that this workflow is not bullet proof. In some\nscenarios a user can handcraft the request headers, therefore being able to\nimpersonate any client. In such cases you could need something more robust,\nlike an OAuth workflow with client id and client secret.\n\nDefaults to `JWT_AUD`.\n\n#### token_header\n\nRequest header containing the token in the format of `Bearer #{token}`.\n\nDefaults to `Authorization`.\n\n#### issuer\n\nThe [issuer claim in the token](https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1).\n\nIf present, it will be checked against the incoming token issuer claim and\nauthorization will be skipped if they don't match.\n\nDefaults to `nil`.\n\n```ruby\njwt.issuer = 'http://myapp.com'\n```\n\n## Development\n\nThere are docker and docker-compose files configured to create a development environment for this gem. So, if you use Docker you only need to run:\n\n`docker-compose up -d`\n\nAn then, for example:\n\n`docker-compose exec app rspec`\n\n## Contributing\n\nBug reports and pull requests are welcome on GitHub at https://github.com/waiting-for-dev/devise-jwt. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.\n\n## Release Policy\n\n`devise-jwt` follows the principles of [semantic versioning](http://semver.org/).\n\n## License\n\nThe gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).\n","funding_links":["https://github.com/sponsors/waiting-for-dev"],"categories":["Ruby","Authentication"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwaiting-for-dev%2Fdevise-jwt","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fwaiting-for-dev%2Fdevise-jwt","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fwaiting-for-dev%2Fdevise-jwt/lists"}