I have been using drf since a couple of months . For authentication I decided to use djoser package and use JWT token for better authentication. However whenever i try to use postman to send requests i can only send the three jwt requests. I'm wondering if i can use the Base endpoints as well such as re-setting the password and finding the user-
Base Endpoints - https://djoser.readthedocs.io/en/latest/base_endpoints.html
Not able to send requests. the error on postman always comes as "detail": "Authentication credentials were not provided."
even if i apply the Bearer Token type in postman.
can someone tell me how to use Base endpoints along with jwt ?
To use JWT with Djoser, send a Get request to
http://127.0.0.1:8000/auth/users/me
Instead of Bearer or Token, Set your Authorization header pass JWT as follows:
Authorization: JWT your-JWT-access-token
Here's a sample request using insomnia
> GET /auth/users/me/ HTTP/1.1
> Host: 127.0.0.1:8000
> Authorization: JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNTk1MDYyNTcxLCJqdGkiOiI2NmZkODFkNDVlNmY0OTdlYWZiMGExZWE2YmRmZmM0MyIsInVzZXJfaWQiOjF9.uXZadgc_hYcS79tuZWet_4eDqNQlduKpcmD1a2JvfjY
if you had set up your urls correctly it will return your username, email and user-ID
Related
I'm trying to write a script to update metadata on various datasets, using an authorized app. Using OAuth seems like the wrong approach (it's not a web-facing application for other users to use as themselves), and passing my own user name and password seems...icky.
The SODA API authentication documentation is pretty confusing:
All HTTP-basic-authenticated requests must be performed over a secure (https) connection, and should include an application token, which is obtained when you register your application. However, authentication [sic, should be "application"?] tokens are not strictly required when a request is authenticated. Authenticated requests made over an insecure connection will be denied.
Here is a sample HTTP session that uses HTTP Basic Authentication:
POST /resource/4tka-6guv.json HTTP/1.1
Host: soda.demo.socrata.com
Accept: */*
Authorization: Basic [REDACTED]
Content-Length: 253
Content-Type: application/json
X-App-Token: [REDACTED]
So:
Can you even use app token + secret token to authenticate with HTTP basic?
Which of the two "[REDACTED]" is the app token, and which is the secret token?
My guess (based on some testing) is that the answers are:
No
The first "[REDACTED]" is the Base64 version of username+password, the second one is the application token, which is not relevant to authentication.
Application tokens and secret tokens aren't actually tied to any sort of pre-baked user authentication. They're tied to your application, and are then used in OAuth to ensure that your app is what it claims to be when the user is passed through the OAuth workflow. Once the user authenticates, the app can retrieve an authentication token that is used to actually authenticate their requests.
What you're really looking for is a way to retrieve a "bearer token", which some API providers allow you to generate. This would allow you to basically "pre-OAuth" and get an authentication token without going through the full workflow. Unfortunately we're not one of them (yet) so you'll need to authenticate with plain old HTTP Basic and your username and password.
If you want a slightly-less-icky way to do that, I recommend registering a "bot" account that you grant only the necessary permissions on the necessary datasets. Then at least you're not baking your regular user credentials into your config. But keep in mind that even if we had bearer tokens, you'd be putting those into your config somewhere.
To answer your more specific questions:
No, because then one of them would have to be a bearer token, which they are not.
The Authorization header is the Base64 encoded username:password, while the X-App-Token is your application token. In this case the latter is just an extra header that would identify that request as having come from your app.
Thanks for your feedback on the docs - I'll clean them up and try to be more straightforward, and I'll definitely fix that typo.
I am looking for an easy way to add bearer tokens to PostMan. I have imported my API into PostMan from a swagger definition, and am wondering if authorization can be added automatically to all requests in some easy way, such that I do not have to change the Authorization header for each endpoint whenever the token changes.
I am currently requesting a token at /token for my API by sending an x-www-form-urlencoded request containing the parameters username, password and grant_type with a password value.
The returned access_token is then appended to the Authorization header in the format "Bearer token-received-from-token-endpoint" for each request to the API.
The backend is implemented with AspNet Identity Framework and AspNet Web API 2.
Good approach here is chaining request
When you get a token, assign it to an environment variable and use that variable in your subsequent requests.
This way you will have a fresh token every time and your other requests can use that on runtime
I'm wondering what is the best appropriate Authorization HTTP header type for JWT tokens.
One of the probably most popular type is Basic. For instance:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
It handle two parameters such as a login and a password. So it is not relevant for JWT tokens.
Also, I heard about Bearer type, for instance:
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
However, I don't know its meaning. Is it related to bears?
Is there a particular way to use JWT tokens in the HTTP Authorization header? Should we use Bearer, or should we simplify and just use:
Authorization: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
Thanks.
Edit:
Or maybe, just a JWT HTTP header:
JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
The best HTTP header for your client to send an access token (JWT or any other token) is the Authorization header with the Bearer authentication scheme.
This scheme is described by the RFC6750.
Example:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIXVCJ9TJV...r7E20RMHrHDcEfxjoYZgeFONFh7HgQ
If you need stronger security protection, you may also consider the following IETF draft: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-pop-architecture. This draft seems to be a good alternative to the (abandoned?) https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-http-mac.
Note that even if this RFC and the above specifications are related to the OAuth2 Framework protocol, they can be used in any other contexts that require a token exchange between a client and a server.
Unlike the custom JWT scheme you mention in your question, the Bearer one is registered at the IANA.
Concerning the Basic and Digest authentication schemes, they are dedicated to authentication using a username and a secret (see RFC7616 and RFC7617) so not applicable in that context.
Short answer
The Bearer authentication scheme is what you are looking for.
Long answer
Is it related to bears?
Errr... No :)
According to the Oxford Dictionaries, here's the definition of bearer:
bearer /ˈbɛːrə/
noun
A person or thing that carries or holds something.
A person who presents a cheque or other order to pay money.
The first definition includes the following synonyms: messenger, agent, conveyor, emissary, carrier, provider.
And here's the definition of bearer token according to the RFC 6750:
1.2. Terminology
Bearer Token
A security token with the property that any party in possession of the token (a "bearer") can use the token in any way that any other party in possession of it can. Using a bearer token does not require a bearer to prove possession of cryptographic key material (proof-of-possession).
The Bearer authentication scheme is registered in IANA and originally defined in the RFC 6750 for the OAuth 2.0 authorization framework, but nothing stops you from using the Bearer scheme for access tokens in applications that don't use OAuth 2.0.
Stick to the standards as much as you can and don't create your own authentication schemes.
An access token must be sent in the Authorization request header using the Bearer authentication scheme:
2.1. Authorization Request Header Field
When sending the access token in the Authorization request header field defined by HTTP/1.1, the client uses the Bearer authentication scheme to transmit the access token.
For example:
GET /resource HTTP/1.1
Host: server.example.com
Authorization: Bearer mF_9.B5f-4.1JqM
[...]
Clients SHOULD make authenticated requests with a bearer token using the Authorization request header field with the Bearer HTTP authorization scheme. [...]
In case of invalid or missing token, the Bearer scheme should be included in the WWW-Authenticate response header:
3. The WWW-Authenticate Response Header Field
If the protected resource request does not include authentication credentials or does not contain an access token that enables access to the protected resource, the resource server MUST include the HTTP WWW-Authenticate response header field [...].
All challenges defined by this specification MUST use the auth-scheme value Bearer. This scheme MUST be followed by one or more auth-param values. [...].
For example, in response to a protected resource request without authentication:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example"
And in response to a protected resource request with an authentication attempt using an expired access token:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="example",
error="invalid_token",
error_description="The access token expired"
The documentation for the Heroku platform API states that it can be accessed with basic HTTP authentication using the API token, as follows:
HTTP basic authentication must be constructed from email address and
api token as {email-address}:{token}, base64 encoded and passed as the
Authorization header for each request, for example Authorization:
Basic 0123456789ABCDEF=.
We have tried this but keep on getting an "Invalid credentials provided" error.
However, if we substitute our Heroku account password for the token, authentication works:
e.g. {email-address}:{password}, base64 encoded.
However, we don't want to have to use our password for API authentication. How do we get this working using the API token as described?
Look again at the same documentation you linked to (it has changed in the meantime).
You should use Authorization: Bearer HEROKU_TOKEN, not Authorization: Basic HEROKU_TOKEN as you are doing.
So having figured out how basic authentication in Web API works with ssl, I want to do the following:
After the client is authenticated, send the client a token (righ now i am thinking that this should just be GUID) with some expiry date, after which the token would render useless and the client will have to authenticate again.
My problem is knowing how the client would send this token in subsequent requests? Should it be sent in:
a) json payload or
b) part of header
If a) then how about GET requests that do not have a body and therefore no json payload?
If b) then what should it be called in the header...or I can just call it anything? Like, authToken: Asdhad-asdlad-82hjf-adkga
Also, since I am using ssl, I do not know if its better to use token or just use user credentials?
Enlighten me on what the standard is here or am I going in the wrong direction?
Thank you.
put the token in the authorization header and name it: "bearer ej304305340Mytoken". SSL is used for authentication of user + password and the subsequent requests with the token.