What could be disadvantage (if any) of using header authorization with a token without Bearer prefix?
Namely my token is a GUID value and it's NOT in the well known format HEADER.PAYLOAD.SIGNATURE, and honestly I don't see any issues with that. However, I doubt that I possibly miss something. Do I?
Thus, my question is if it's bad decision to have the token string to be simply a GUID?
Probably a poor decision but we don't know your security requirements.
The bearer token is an industry standard in token authentication. I recommend doing a little research so you understand the standard. Then you can make a decision. Given the little information you have provide, I would fail the design in a code review
with the recommendation to use standards.
The main disadvantage of using a guid as token, is it requires a server lookup to translate the token to user credentials, while a bearer token just requires decryption or validation. If your app requires persistent state also then this may not be an issue.
Probably a poor decision but we don't know your security requirements.
Basically, it is an API that returns JSON data to the consumers. The data itself is not so sensitive but, anyway I plan to have some really sensitive data over there and I want to be 100% sure if I should keep using the GUID as token or follow the standards?
From what I read here it seems that I should stick to the standard anyway. Right?
The main disadvantage of using a guid as token, is it requires a server lookup to translate the token to user credentials, while a bearer token just requires decryption or validation. If your app requires persistent state also then this may not be an issue.
Actually all that I do is checking against the database if certain token (GUID) is present and if it's not expired. I do not translate nor decrypt anything. Meaning, as said it is a very basic API with
IAuthorizationFilter set to guard the controllers (endpoints).
you POST your username and pwd e.g. {"username":"admin","pwd":"123"} to https://api.domain.com/auth
if the login is valid you get your token in the response
you make new GET request adding the token in the header (Authorization)
Hmm I am not quite sure that I understand the last answer.
Do you say that I SHOULD use JWT Bearer Token if my API code has access to the database?
Also I was wondering if it's OK to have a non-standard Bearer token and still making the consumers to use it like it is a bearer token? e.g. Authorization: Bearer <non-standard-formatted-token>
OR I need to set the format according to the standard in case I want to use Bearer authorization?
Also I was wondering if it's OK to have a non-standard Bearer token and still making the consumers to use it like it is a bearer token? e.g. Authorization: Bearer <non-standard-formatted-token>
OR I need to set the format according to the standard in case I want to use Bearer authorization?
It seems like you made up your mind before asking this question. I would use a JWT because JWT is an industry standard. Frameworks like .NET come with libraries for handling JWTs and most clients software already know how to handle JWTs. I prefer to use
existing libraries rather than writing and testing a custom solution.
Design and implement whatever you like and if that design is an Authorization header with a bearer guid then great. You just need to let the clients know how the token works and the client will need to write a little custom code.
It seems like you made up your mind before asking this question. I would use a JWT because JWT is an industry standard. Frameworks like .NET come with libraries for handling JWTs and most clients software already know how to handle JWTs. I prefer to use
existing libraries rather than writing and testing a custom solution.
Design and implement whatever you like and if that design is an Authorization header with a bearer guid then great. You just need to let the clients know how the token works and the client will need to write a little custom code.
Ha you are right. I am just looking for a confirmation :)
Thank you for the good points. It's much appreciated
Member
117 Points
511 Posts
Bearer Token
Feb 19, 2021 10:44 AM|KulerMaster|LINK
Hello Guys,
What could be disadvantage (if any) of using header authorization with a token without Bearer prefix?
Namely my token is a GUID value and it's NOT in the well known format HEADER.PAYLOAD.SIGNATURE, and honestly I don't see any issues with that. However, I doubt that I possibly miss something. Do I?
Thank you in advance
All-Star
52971 Points
23574 Posts
Re: Bearer Token
Feb 19, 2021 12:27 PM|mgebhard|LINK
I think you are asking about JavaScript Web Tokens (JWT).
https://jwt.io/introduction
Member
117 Points
511 Posts
Re: Bearer Token
Feb 19, 2021 03:04 PM|KulerMaster|LINK
Actually no. This is an API with authentication. They send username and password and get token which imo doesn't need to be a Bearer.
Thus, my question is if it's bad decision to have the token string to be simply a GUID?
Thanks
All-Star
52971 Points
23574 Posts
Re: Bearer Token
Feb 19, 2021 03:24 PM|mgebhard|LINK
Probably a poor decision but we don't know your security requirements.
The bearer token is an industry standard in token authentication. I recommend doing a little research so you understand the standard. Then you can make a decision. Given the little information you have provide, I would fail the design in a code review with the recommendation to use standards.
All-Star
58134 Points
15641 Posts
Re: Bearer Token
Feb 19, 2021 03:30 PM|bruce (sqlwork.com)|LINK
The main disadvantage of using a guid as token, is it requires a server lookup to translate the token to user credentials, while a bearer token just requires decryption or validation. If your app requires persistent state also then this may not be an issue.
Member
117 Points
511 Posts
Re: Bearer Token
Feb 19, 2021 07:16 PM|KulerMaster|LINK
Basically, it is an API that returns JSON data to the consumers. The data itself is not so sensitive but, anyway I plan to have some really sensitive data over there and I want to be 100% sure if I should keep using the GUID as token or follow the standards?
From what I read here it seems that I should stick to the standard anyway. Right?
Member
117 Points
511 Posts
Re: Bearer Token
Feb 19, 2021 07:25 PM|KulerMaster|LINK
Actually all that I do is checking against the database if certain token (GUID) is present and if it's not expired. I do not translate nor decrypt anything. Meaning, as said it is a very basic API with IAuthorizationFilter set to guard the controllers (endpoints).
Thank you so much
All-Star
58134 Points
15641 Posts
Re: Bearer Token
Feb 19, 2021 10:53 PM|bruce (sqlwork.com)|LINK
then thats fine. the use of JWT bearer Tokens is to avoid a database access or a 3rd party source (your code does not have access to the database).
Member
117 Points
511 Posts
Re: Bearer Token
Feb 20, 2021 11:41 AM|KulerMaster|LINK
Hmm I am not quite sure that I understand the last answer.
Do you say that I SHOULD use JWT Bearer Token if my API code has access to the database?
Also I was wondering if it's OK to have a non-standard Bearer token and still making the consumers to use it like it is a bearer token? e.g. Authorization: Bearer <non-standard-formatted-token> OR I need to set the format according to the standard in case I want to use Bearer authorization?
Thank you
All-Star
52971 Points
23574 Posts
Re: Bearer Token
Feb 20, 2021 12:51 PM|mgebhard|LINK
It seems like you made up your mind before asking this question. I would use a JWT because JWT is an industry standard. Frameworks like .NET come with libraries for handling JWTs and most clients software already know how to handle JWTs. I prefer to use existing libraries rather than writing and testing a custom solution.
Design and implement whatever you like and if that design is an Authorization header with a bearer guid then great. You just need to let the clients know how the token works and the client will need to write a little custom code.
Member
117 Points
511 Posts
Re: Bearer Token
Feb 20, 2021 01:28 PM|KulerMaster|LINK
Ha you are right. I am just looking for a confirmation :)
Thank you for the good points. It's much appreciated