I've setup oidc-provider for pkce (v7x). When I do the following:
request a code from /auth with response_type='code'
Used the code to get token form /token with grant_type=authorization_code
Receive token as shown:
{
access_token: "a8DM82TgXF-cjlzH8yOjuK6_OF9h_JaYJjSPrAdCRG0"
expires_in: 86400
id_token: "eyJhbGci....FQg"
scope: "openid"
token_type: "Bearer"
}
How can I get node-oidc-provider to return a JWT access_token with claims?
You shall use the Resource Indicators feature (oidc-provider docs) and request an access token for a particular resource server, in the resource indicators feature the configuration getResourceServerInfo is for validating the resource indicator provided (or defaulted to) in the authorization request. The return value from this getResourceServerInfo helper also defines the access token format (accessTokenFormat property), when the value is jwt the resulting Access Token is, well, a JWT following the JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens.
Related
I'm trying to connect to an API of a website using Token Authorization in Postman.
So the URL that I'm trying to connect is a GET URL that goes like this:
https://seller.digikala.com/api/v1/profile/
And then at Postman, I set the Authorization type to BearerToken and copied and pasted the token.
And Headers is also set to Content-Type of application/json:
But I don't know why I get this error:
{
"status": 401,
"message": "Invalid token!"
}
I also test the token at the jwt.io website and it says: Invalid Signature!
So the question is, does the website provide me a wrong and invalid token (because I just copy and paste it and no chance of entering an incorrect token)?
What are the other ways for authorizing this token and how can I get the proper response?
BearerToken is not always JWT
BearerToken is a type of Authorization Header, you can pass to an http endpoint.
BearerTokens can have multiple token_type, like:
jwt,
api_token,
...
the BearerToken is not always jwt, it can have multiple algorithm.
the 12|xxx format is like api_token
Note: one of the signs if you want to know the token is jwt, if its
format is url encoded string with 2 dots, (xxx.yyy.zzz) its a chance
that it would be JWT token
Validating JWT
in the jwt.io you should provide the digikala.com public key to validate the signature.
It said invalid token, because you haven't provide, digikala
public key
but as decoder showed up, the token you have provided is a jwt token with payload data of :
{
"token_id" : 970,
"payload" : null
}
TD;DR
I guess you can access if you login again and try new token
Is it possible to use Google Header Auth with an API_KEY?
At the moment we are downloading files using:
https://www.googleapis.com/drive/v3/files/{fileId}?alt=media&key={our API key}
We want to migrate to using HTTP Header auth like this:
GET https://www.googleapis.com/drive/v3/files/[FILEID] HTTP/1.1
Authorization: Bearer [YOUR_ACCESS_TOKEN]
Accept: application/json
The first method uses our own API_KEY from Google Cloud Console.
The second method uses an ACCESS_TOKEN created by the user authenticating with the app with oAuth.
Is it possible to use our API_KEY for HTTP Auth? Or do we have to use the users ACCESS_TOKEN?
API key grants you access to public data only.
An access token is an authorized token which gives an application access to user data.
They are two different things.
The authorization header is used for sending authorization bearer tokens, access tokens to the server to authorize a request.
No you can not send an api key as a authorization header as it is not a bearer token. You need to authenticate your users using Oauth2 in order to get access to their data, which will give you an access token and the ability to add that as a authorization header and request access to download the users file.
I understand that a resource server will make a call to the authentication server with a token to confirm that it is valid.
However is this token the same Cookie: JSESSIONID?
Oauth 2.0 Bearer tokens are of two types - General tokens(e.g like java uuid string) and JWT tokens.
General tokens will be stored in the authorization server token store along with their scopes, expiry, client ID, UserId and other related information. When client sends request to resource server, Resource server need to reach out authorization server(Spring oauth 2.0) for bearer token validation.
JWT tokens contains information about its expiry along other user information and self sufficient to work in stateless sessions, Here we don't need to validate oauth 2.0 JWT tokens from authorization server.
JSESSIONID Cookie is created by spring security by default, its not related to Bearer token authorization.
Well the standard solution is an introspection request, as in step 14 of this post: https://authguidance.com/2017/09/26/basicspa-oauthworkflow/
Not all solutions are standards based though - and I always recommend capturing the HTTP traffic
I am trying to create an oAuth policy to protect an API using an JWT access token. That token can be validated by calling an external URL.
I am using the following RAML for my Mule proxy.
#%RAML 1.0
title: Custom API
version: 1
baseUri: http://localhost:8081
securitySchemes:
oauth_2_0:
description: |
This API supports OAuth 2.0 for authenticating all API requests.
type: OAuth 2.0
describedBy:
headers:
authorization:
description: |
Used to send a valid OAuth 2 access token. Do not use with the "access_token" query
string parameter.
type: string
responses:
401:
description: |
Bad or expired token. This can happen if the user or the API revoked or expired an
access token. To fix, you should re-authenticate the user.
403:
description: |
Bad OAuth request (wrong consumer key, bad nonce, expired timestamp...). Unfortunately,
re-authenticating the user won't help here.
/hello:
get:
securedBy: [oauth_2_0]
However, mule is not able to send the Authorization header while validating against the external service.
The RAML that you posted is fine, but informative only. You have to implement the JWT oAuth token enforcement capability either as a custom policy or as part of your Mule flow. Currently, there is no out-of-the-box policy for JWT token validation.
Usually, for validating a token, an external endpoint is called providing the token as part of the internal [policy] request. That means that the policy itself will parse the incoming user request, and extract the token either from the query params or from the Authorization header (removing the bearer part). AFAIK, Authorization header is never sent to the introspection token URL.
On successful login to my spring security application configured with Oauth2, I received a response with Oauth2 token.
For the subsequent request I passed Oauth2 access_token in URI Query Parameter like this
http://localhost:8090/myapplication/users/user?access_token=4c520795-eb07-4c2d-a91b-474c85fb481e
It is working fine.
But instead of passing token in URI to make it more secure I wanted to send token in request headers.How to do this?
Use the usual HTTP Authorization header:
Authorization: Bearer <your-token-here>
For example
Authorization: Bearer 4c520795-eb07-4c2d-a91b-474c85fb481e