Lexik JWT returns 401 Unauthorized

Question

I am using LexikJWTBundle for a RESTful API.

The input works very well and I get my token. But when I make a GET request, I get 401 without content. The authorization header looks fine, since I get it in the profiler: Request headers: authorization: Media {token} Request server parameters: HTTP_AUTHORIZATION: Bearer {token}

401 I get from: https://github.com/lexik/LexikJWTAuthenticationBundle/blob/master/Security/Firewall/JWTListener.php#L80

I tried different solutions, but still did not work.

Do you have an idea on how to enable / debug this?

My configuration:

# config.yml ... lexik_jwt_authentication: private_key_path: %kernel.root_dir%/var/jwt/private.pem # ssh private key path public_key_path: %kernel.root_dir%/var/jwt/public.pem # ssh public key path pass_phrase: 'TEST' # ssh key pass phrase token_ttl: 86400 # token ttl - defaults to 86400 

and

 # security.yml security: role_hierarchy: ROLE_SUPER_ADMIN: [ROLE_ADMIN, ROLE_SONATA_ADMIN, ROLE_ALLOWED_TO_SWITCH] # http://sonata-project.org/bundles/admin/2-3/doc/reference/security.html # set access_strategy to unanimous, else you may have unexpected behaviors access_decision_manager: strategy: unanimous encoders: FOS\UserBundle\Model\UserInterface: sha512 providers: fos_userbundle: id: fos_user.user_provider.username_email firewalls: dev: pattern: ^/(_(profiler|wdt)|css|images|js)/ security: false api_login: pattern: ^/api/login # Default: .* provider: fos_userbundle # form login form_login: login_path: fos_user_security_login # csrf_provider: form.csrf_provider # Default: my.csrf_provider.id # LexikJWT # 09/01/15 - Note: provient de la configuration officielle. check_path: api_login_check success_handler: lexik_jwt_authentication.handler.authentication_success failure_handler: lexik_jwt_authentication.handler.authentication_failure require_previous_session: false anonymous: true # Default: ~ api: pattern: ^/api stateless: true lexik_jwt: authorization_header: # check token in Authorization Header enabled: true prefix: Bearer anonymous: true access_control: # Secured part of the site # This config requires being logged for the whole site and having the admin role for the admin part. # Change these rules to adapt them to your needs - { path: "^/api/contacts$", roles: IS_AUTHENTICATED_ANONYMOUSLY, methods: [POST] } - { path: "^/api/users/dt$", roles: IS_AUTHENTICATED_ANONYMOUSLY, methods: [GET] } - { path: "^/api/users$", roles: IS_AUTHENTICATED_ANONYMOUSLY, methods: [POST] } - { path: "^/api", roles: [IS_AUTHENTICATED_FULLY, ROLE_API] } 

Answer 1

I found a solution to the same problem

Here is my security.yml

 firewalls: dev: pattern: ^/(_(profiler|wdt|error)|css|images|js)/ security: false login: pattern: ^/api/login stateless: true anonymous: true provider: user_db form_login: check_path: /api/login_check username_parameter: _username password_parameter: _password success_handler: lexik_jwt_authentication.handler.authentication_success failure_handler: lexik_jwt_authentication.handler.authentication_failure require_previous_session: false api: pattern: ^/api stateless: true lexik_jwt: authorization_header: # check token in Authorization Header enabled: true prefix: Bearer throw_exceptions: false # When an authentication failure occurs, return a 401 response immediately create_entry_point: true # When no authentication details are provided, create a default entry point that returns a 401 response authentication_provider: lexik_jwt_authentication.security.authentication.provider 

My problem was the username and password settings. I change "username to " _ username and "password " _ password "

Answer 2

You must add ROLE_API in the role_hierarchy your security.yml:

 role_hierarchy: # ... ROLE_API: [ROLE_USER] 

Users with a ROLE_API rating can then access routes restricted to IS_AUTHENTICATED_FULLY .

Also, if you are using a web server, try using the application using the built-in server (i.e. app/console server:run ).

Apache seems to be modifying the token in the headers.

Answer 3

LexikJWTBundle generates a token, so the user credentials are valid. The problem occurs when trying to access protected routes (along the path "^ / api").

Be sure to check the roles assigned to the user. Perhaps ROLE_API is missing and the user is not fully authenticated.