Submitted via IRC for SoyCow7671
Four Most Used REST API Authentication Methods - DZone Security
While there are as many proprietary authentication methods as there are systems that utilize them, they are largely variations of a few major approaches. In this post, I will go over the four most used in the REST APIs and microservices world.
Authentication vs. Authorization
Before I dive into this, let's define what authentication actually is, and more importantly, what it's not. As much as authentication drives the modern internet, the topic is often conflated with a closely related term: authorization.
The two functions are often tied together in single solutions, but the easiest way to divide authorization and authentication is to ask: what do they actually state or prove about me?
Authentication is when an entity proves an identity. In other words, Authentication proves that you are who you say you are. This is like having a driver's license that is given by a trusted authority that the requester, such as a police officer, can use as evidence that suggests you are in fact who you say you are.
Authorization is an entirely different concept and in simple terms, Authorization is when an entity proves a right to access. In other words, Authorization proves you have the right to make a request. Consider the following — You have a working key card that allows you to open only some doors in the work area, but not all of them.
Four Most Used Authentication Methods:
- HTTP Authentication Schemes (Basic and Bearer)
- API Keys
- OAuth (2.0)
- OpenID Connect
(Score: 4, Informative) by Pino P on Monday August 12 2019, @03:14PM
From the featured article:
One common insecure point is the RAM of the end user's device between loading an application on a user's device and when it submits the request to the API. This is the case for what the OAuth 2 spec calls a "public client," or a desktop or mobile application or the client side of a web application.
Any user with a debugger can start a public client, observe the query signing process of OAuth 1 or the header building of OAuth 2, read out the client ID and secret, and impersonate an application. Impersonating an application misuses the application's request quota allocation and policy compliance reputation. Misbehavior with a key copied out of a public client can cause the service provider to disable access an otherwise compliant application, making the application stop working for its users.
There are supposed to be ways for a public client to create its own client secret, such as dyn-reg (RFC 7591) [ietf.org] and PKCE (RFC 7636) [oauth.com], but I haven't seen evidence of their wide adoption.
Further reading about API key secrecy: "Dear Twitter: Stop screwing over your developers." by Nelson Elhage [nelhage.com]
(Score: 0) by Anonymous Coward on Monday August 12 2019, @04:59PM
so "your" "passwd" file is on a NFS share and the share is on hardware that belongs to someone randomly else?
(Score: 0) by Anonymous Coward on Monday August 12 2019, @10:57PM
Which authentication method do Soylentils prefer when consuming an API?