so I am working with a 3rd party RESTful webservice where I have to authenticated myself by requesting a JWT and provide it to any further requests.
I do that by just posting my username and password and recieve a token for this. I neither know the secret used to create the token nor anything else besides username and password.
Now, I would like to check the expiration time of the JWT before I either reuse it for subsequent webservice requests or just renew it. I know i could just used it and catch some kind of expiration exception but I would prefer not to.
I tried to follow this tutorial: [https://stormpath.com/blog/token-auth-for-java]
but get stuck at the point where I have to provide signing key.
How would I do that since I do not have the secret used to encode it.
Bye the way: I am working with groovy and wslite on this one.
You should just be able to take the body of the token, and decode it.
The private key isn't used to encrypt the body of a JWT, it's just used to generate the signature...
So, in Groovy you can just do:
// A JWT from the link you gave above
String key = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vdHJ1c3R5YXBwLmNvbS8iLCJleHAiOjEzMDA4MTkzODAsInN1YiI6InVzZXJzLzg5ODM0NjIiLCJzY29wZSI6InNlbGYgYXBpL2J1eSJ9.43DXvhrwMGeLLlP4P4izjgsBB2yrpo82oiUPhADakLs'
// Just the body (middle section)
String body = key.split(/\./)[1]
// Un base64 it (using the Java 8 Base64 class)
String unencoded = new String(Base64.decoder.decode(body), 'UTF-8')
// Parse the json into a map
Map data = new groovy.json.JsonSlurper().parseText(unencoded)
// Get the expiry
long exp = data.exp
assert exp == 1300819380
Of course, there's nothing to say that the body of the token has to contain any form of expiry time for you to look at... It could just be an internal ID
If you don't know the cipher used to encode it nor want to crack their cipher then you can't decode any information from the token. There is nothing like 'standard information that must be encoded in token', there's no need to the token that it should contain any ciphered information at all, it could be just an randomly generated UUID stored on their side in DB, so in that case you can't decode it at all.
Related
I am building a Django Rest Framework API which is using JWT authentication. I had created access tokens and refresh tokens and sent them to users.
I also have a refresh token endpoint that will take old refresh token and generate new pair of tokens and send to user.
I have doubt in its behavior related part. Currently what I can see that whenever I create new pair of access and refresh token using previous refresh token, the old access token is also working and new one is also working.
However once when I was using OAuth2.0 (in different case), I observed that in that case the old access token won't work if we had created new refreshed tokens.
But in case of my implementation of JWT in DRF this thing won't happens. I am not storing token in database.
So I want to know that is this any implementation specific problem or is it the property of JWT only, and if it is property then please share some details over it with me.
Thanks.
According to JWT introduction:
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
One of the value, that you can encode is 'exp' which states for expiration date. That's why your old tokens do not expire, cause they expiration date is still valid, and any other claims didn't change. Idea behind the 'refresh' token, is to provide new tokens with bigger exp value. Saying other way, you should not expect that the authorization will fail now, as the old token is still correct one.
As well you store nothing in the database (about this I also suggest to read answer provided by #sdoxsee
Having issue with http transformation simple post with bearer token.
So, we have a mapping that uses http transformation to SIMPLE POST JSON data into an api. The api uses bearer token authorization. So you send a user/pass and get a token back and then POST your json data with the token in the header.
But when we are trying to POST along with token, we are facing issues. Basically i am not sure how to post json data with token in the header info.
Anyone have any ideas ?
It worked with below approach for Barer token.
Flow:
SQ->exp->HTTP->exp->HTTP->TGT
HTTP connection:
Base URL : Provide the login URL for the API
Authentication : Basic
First HTTP transformation:
Give the login URL in Base URl. Pass a single row as an input for trigger of URL. This should give the generated token as an output (JSON/XML).
Pass the output to expression transf. Add a new output port and extract the token value only.
output port value : 'Bearer '||substr(ouput,2,30)
Methods - POST
Second HTTP transformation:
Add new input port and connect the above expression output as input.
Add new Header port as "Authorization".
Provide the API URL in the base url.
Methods - POST
Connect the output port to Flat file to check the received response.
Note: Do not give/select any connection details to this transformation.
Bearer token is another token-based authorization technique where if you pass user/pass to the token-generating API, it returns a token. You attach that token to API tool (postman, insomnia, or informatica) and POST your data to another API which will process the data.
Now, issue is, token can expire fast or slow. Fast expiring token need to be managed so that API call finishes before expiry. For us luckily its 24hrs.
First, get the token using HTTP trx by passing userid/pass.
Then, I pass the token as part of header column in HTTP transformation.
Methods I used - SIMPLE POST for both trx.
EDIT : Per request from an user, i am adding this edit.
The user and pass in the EXP transformation is hardcode values. And they were added to a json format that auth api can recognize.
The output of http_auth transformation is a token. If hardcode is a problem, you can read user and pass from a file from a secured location.
This token is used in the next json. This next json is created using the token as well as input data to the actual api. The api catches them, validates them against token and then write the data into api DB.
Try postman.. It will give you the code as well. It supports quite a few commonly used development languages
Is token supposed to be stored only in client-side not in server-side?
from rest_framework.authtoken.models import Token
Django-rest have a model for token, that means token is stored in database.
So why Django-rest store token in database?
It depends on the token type
Some tokens are just a unique random string and the only way of knowing which user is associated with it is to store it somewhere and then look it up when needed.
There is also another type of token which doesn't need to be stored. Basically, you encrypt the token string with a key and then send it to the user.
The string must include some sort of data that you can find the user with.
For example, you can create a token string like this: userID=2-some-random-string. Then you encrypt this string with a key and any algorithm you think that will work best for you and pass it to the user. When you receive the token from a user, all you need to do is to decrypt it using the key and extract the user id from that string. if there wasn't any user id or token failed to get decrypted, then the token is not valid.
Django rest framework uses the first type of tokens which they need to be stored somewhere.
There are other libraries for rest framework that works with other types of tokens. You can choose between all of them based on your needs or even you can create one yourself.
I've read numerous token based authentication articles and they typically fail to explain how the server verifies token. I understand that:
User Requests Access with Username / Password
Application validates credentials
Application provides a signed token to the client
Client stores that token and sends it along with every request
Server verifies token and responds with data
But how does step 5 specifically happen?
The token-based authentication terminology can be used in a few contexts so the answer will always depend on the exact question. You did tag your question with JWT (JSON Web Tokens) so I'll answer this by drawing a few assumptions based on that tag.
JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with HMAC algorithm) or a public/private key pair using RSA.
(emphasis is mine, source: see link above)
This definition sheds some light on your exact question on how a server application verifies a token. It does it, in the case of a JWT, by checking if the associated digital signature is valid; it actually does more than just checking the signature, but this is the most important step.
Digital Signature: A cryptographic method for ascertaining whether or not a digital message or set of documents is genuine, has not been altered or tampered with in transit, and comes from a known sender.
(source: Auth0 Identity Glossary)
You can digitally sign something by applying different algorithms, but this process can be described at a very high-level to consist of the following:
Select a secret that only you (your server) will know about.
Pass the secret and data to be signed to a given algorithm.
The output will consist of a signature that can then be later used to check (if you also know the secret) if some data is exactly equal to the one that originally produced the signature.
In conclusion a server generates a JWT which is signed, distributed to any client application and as long as the server ensures the secret used to sign it is known to no one else it can ensure that the received tokens were not tampered with and were in fact issued by a trusted party.
As mentioned before, the server besides checking the signature can do further validations, usually it will at least also validate that the token is still valid in terms of lifetime. This is recommended because this authentication process that relies purely on having a token, usually referred to as a bearer token, means that if an attacker is able to get hold of a token it can only use it within is configured lifetime. A derived recommendation is that the lifetime of bearer tokens should also be relatively short.
It depends. The token can be a hash of the username the password and a key that the client generates, it can be just random and stored in a db, there is not a unique answer for this
I am developing a restful web service and it needs securing. I am doing this using a token system where the client passes a token unique to them via the request header. The service has to be called via HTTPS.
I have seen a few articles which encrypt the token but is there any real benefit to doing this as the token would naturally be encrypted by HTTPS anyway....?
After re-reading the above I realise that it is not entirely clear what I meant...
The articles I have seen give the client a pre-encrypted Token which was encrypted with a public key. They then decrypt this token on receipt of the request and check it against the stored unencrypted token. To me it seems that this has no benefit over simply giving the client an unencrypted token and saving on the whole decryption overhead....
I think it's a broad question and the answer will depend on your requirements. But, in most of cases, you won't need cryptography in your identity tokens.
Identity tokens (used to perform authentication) can be opaque (tokens that reveal no details other than the value itself, like a random string) or can be self-contained (like JSON Web Tokens).
For more details, see below:
Random string
A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.
JSON Web Tokens (JWT)
Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64. The payload can be decoded and read by the client.
With JWT, you can perform stateless authentication, that is, you won't need to persist JWT tokens if you don't need to track them. Just check the integrity of the token by verifying its signature on the server side.
Although, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To keep the track of JWT tokens, instead of persisting the whole token, you could persist the token identifier (the jti claim) and some metadata (the user you issued the token for, the expiration date, etc) if you need. To find some great resources to work with JWT, have a look at http://jwt.io.
For tokens with cryptography, have a look at JSON Web Encryption (JWE), defined in the RFC 7516. Use JWE when you need confidentiality, so the client will need a key to decrypt the content of the token.