Timeline for Where to place an API key: a custom HTTP header VS the Authorization header with a custom scheme
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 30, 2017 at 22:58 | history | tweeted | twitter.com/StackSoftEng/status/936368746586886147 | ||
| Nov 30, 2017 at 3:10 | comment | added | K. Alan Bates | (drive by) ...please take care to know that api keys are shared secrets typically shared between a configured relying party and an authenticator, not to communicate identity or authorization. Stated another way, they are only intended to initiate a security handshake, not represent an authentication result. The api key communicates your authority to identify yourself against the system's trusted authenticator. Using the key as an token to control secure resource access is bad juju | |
| Jul 21, 2017 at 20:34 | vote | accept | RomanG | ||
| Jul 20, 2017 at 21:05 | comment | added | Andy | You're limiting yourself too much. The API consumer could not care less whether you have implemented OAuth or not. What they care about is token safety, that token issuing works and that they can get properly authenticated. They recommend to use Bearer right in the JWT documentation. JWT fits the Bearer schema perfectly well and I could not recommend JWTs more. They are perfect for REST applications because you can authenticate a user even without hitting the database - unless you need token revocation feature. | |
| Jul 20, 2017 at 20:13 | comment | added | RomanG |
@DavidPacker Then I understood, that the ApiKey authorization could be considered as a valid oAuth implementation if ApiKey was renamed and interpreted as an Access Token granted to the client without an expiration time. That's a kind of philosophical aspect, I decided not to bring complex definitions if my case can be described in simple terms and decided to just call it "ApiKey". If your protocol implements oAuth standart, I can agree on using Bearer, but it doesn't, I guess this scheme can't be applied.
|
|
| Jul 20, 2017 at 20:13 | comment | added | RomanG |
@DavidPacker As I understand, Bearer scheme is used exclusively with oAuth2. Applying it separately from oAuth sounds as misusing it. Why is it correct to use this scheme if there is no oAuth? By the way, I had troubles with choosing a type of authorization for my API. The API will be available only for one trusted service, so I investigated the client credentials flow of oAuth2 and haven't found any benefit in comparison with ApiKey in my case.
|
|
| Jul 20, 2017 at 15:20 | comment | added | Andy |
The projects under my guidance use Authorization: Bearer <token> header and there was never a single issue with that. The tokens are JWTs.
|
|
| Jul 20, 2017 at 13:48 | answer | added | Laiv | timeline score: 23 | |
| Jul 20, 2017 at 13:09 | history | edited | RomanG | CC BY-SA 3.0 |
fixed grammar
|
| Jul 20, 2017 at 8:55 | review | First posts | |||
| Jul 24, 2017 at 19:41 | |||||
| Jul 20, 2017 at 8:51 | history | asked | RomanG | CC BY-SA 3.0 |