I am passing oauth2 token in Request header as Authorization: Bearer . But if you use for example Chrome developer tools you can see the token and basically copy it and use it to call our services. How can I prevent/hide the token so it does not show in developer tools.
Developer tool are not designed to hide any data (e.g. you can use them to send cookies as well). So if you don't trust your users then don't issue tokens that can be used from an arbitrary client.
Related
Within my Laravel 9 (Jetstream) installation, I've createad an account (admin) and also created an API token for it directly from the user interface available by default. So the API has an account and an API token for it.
I am able to login to my (Laravel) API, using that token as a Bearer token method 'Authorization: Bearer '.
Everything fine for now, I can access protected routes of the API that are only available for logged-in users.
I've implemented this approach within my frontend app (SPA), which is on a different domain.
At a certain point in my frontend app, I need to communicate with my API, so I am doing a request to it using the same approach like I did in Postman. Basically, within my (axios) request, I am configuring the route to the api, and also the required header (Authorization: Bearer xxxx) to authorize the request using the Bearer token.
axios.post(
'url',
{
"body": data
},
{
headers: {
'Authorization': 'Bearer <my token>'
}
}
)
Now, my main problem is that this request (including the token) can be seen in Chrome Developer tools for example (or other request trackings tools)
How can I secure this in a easy and strong way?
For those who know more about Laravel, this way of authorization that comes from Jetrstream is Sanctum, and comes out of the box. I know there's another method of creating tokens, by making an initial request to the API using basic auth, and in response, I'll get a token that I should use for each request. But does that mean that it's more secure? In the end, that "fresh" token will be also visible to next requests, right? Even if it will be deleted on logout. If someone sees that token, he can easily make a request to my API using it and pretend to be a logged in user.
Is JWT a solution?
There must be something that I'm missing here. Any solutions are welcome
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 have a Web API and AngularJS client. The API is using default authorization provider given by visual studio to generate the token on token request with grant_type 'password'.
The AngularJS client is able to get the bearer token from Web API by calling the token endpoint with credentials and later passes this token to perform authorized requests in the API.
When AngularJS sends the token on any authorized API call, how is Web API able to validate the token? Where does the token get stored?
I checked in Identity tables in SQL server, I could not find any fields to store this token information. I checked in the configuration file, it is not stored there either. Could you please help me in understanding this concept?
Raj,
By default the token is not stored by the server. Only your client has it and is sending it through the authorization header to the server.
If you used the default template provided by Visual Studio, in the Startup ConfigureAuth method the following IAppBuilder extension is called: app.UseOAuthBearerTokens(OAuthOptions).
This extension coming from the Microsoft.AspNet.Identity.Owin package makes it easy for you to generate and consume tokens, but it is confusing as it is an all in one.
Behind the scene it's using two Owin middlewares:
OAuthAuthorizationServerMiddleware: authorize and deliver tokens
OAuthBearerAuthenticationMiddleware: occurs at the PipelineStage.Authenticate, read the authorization header, check if the token is valid and authenticate the user.
To answer you questions WebAPI is able to validate the token thanks to the OAuthBearerAuthenticationMiddleware, it will ensure that the token sent through the authorization header is valid and not expired. And the token is stored only by your client, if the client loose it, it will have to request a new one.
I advise you to get deeper in the OAuth protocol, and instead of using the extension UseOAuthBearerTokens, take a look at UseOAuthAuthorizationServer and UseOAuthBearerAuthentication, it will help you to better understand how it works.
The generated token will most likely be a JWT (Get Started with JSON Web Tokens), which means it's a self-contained token that is signed with a secret/key that only the server or other trusted parties know.
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.
(emphasis is mine)
This means that when receiving the token the server can ensure that:
the token was originally issued by a trusted party by checking that the signature is valid.
the token is associated with a user that has permissions to perform the following request because the token itself contains information that uniquely identifier that user.
This type of approach has the side-benefit that the server does not need to keep track or store the generated tokens in order to validate them at a later time. Since no one else has the secret/key you can't modify the token without making the signature component invalid, which would then mean a faked token would end up being rejected by the server.
This is a simplified description of what happens, there are much more details around how to issue and validate tokens correctly. You should read the OAuth2 and OpenID Connect specification to learn more on the subject of token-based authentication.
Also note that I assumed a JWT token because it's the format that currently has the most widespread adoption to accomplish scenarios like these ones and it's also the token format to use in conjunction with OAuth2 and OpenID Connect. However, it's still possible to achieve the same with other token formats.
I'm wondering is it "legitimate" to provide the JWT token I received back from Identity Server to the page so that Javascript can make ajax calls with it as a bearer token to several API endpoints. Clearly these end points would be using SSL, but is this a typical/correct usage pattern?
Cheers,
P
It is certainly doable - if you are OK with the access token being on the client machine/device.
I am developing an API using Codeigniter and Oauth2 (Alex Bilbies library).
The API is being used by my iPhone app. For every request I need to send along the access token as a parameter in the URL. Is there a way to send the token in a header instead? To avoid it getting "exposed"?
Thankful for all input!
OAuth 2.0 bearer tokens allow you to insert them in an HTTP Authorization header as follows:
POST /my/api HTTP/1.1
Host: rs.company.com
Authorization: Bearer abcdef123456
Where abcdef123456 is your Access Token (see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-bearer-16#section-2.1). In fact the spec says you SHOULD do that in lieu of request parameters if it is possible.
The spec also describes many security considerations when using OAuth 2.0 bearer tokens (see: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-bearer-16#section-4)
Sending an access token over GET is just as insecure as sending it in a header.
OAuth 1 used to get around this with all sorts of encryption, secured passwords, hell you could even turn certifications on. This was all a massive ball-ache, so now in OAuth 2 you just have to use HTTPS which does all of this for you.