Ask HN: What's the recommended method of adding authentication to a REST API? - somtum
======
tptacek
This question comes up all the time on HN. I'm one of a bunch of people on HN
that do this kind of work professionally. Here's a recent comment on a recent
story about it:

[https://news.ycombinator.com/item?id=16006394](https://news.ycombinator.com/item?id=16006394)

The short answer is: don't overthink it. Do the simplest thing that will work:
use 16+ byte random keys read from /dev/urandom and stored in a database. The
cool-kid name for this is "bearer tokens".

You do not need Amazon-style "access keys" to go with your secrets. You do not
need OAuth (OAuth is for _delegated authentication_ , to allow 3rd parties to
take actions on behalf of users), you do not need special UUID formats, you do
not need to mess around with localStorage, you do not need TLS client
certificates, you do not need cryptographic signatures, or any kind of public
key crypto, or really any cryptography at all. You almost certain do not and
will not need "stateless" authentication; to get it, you will sacrifice
security and some usability, and in a typical application that depends on a
database to get anything done anyways, you'll make those sacrifices for
nothing.

Do _not_ use JWTs, which are an increasingly (and somewhat inexplicably)
popular cryptographic token that every working cryptography engineer I've
spoken to hates passionately. JWTs are easy for developers to use, because
libraries are a thing, but impossible for security engineers to reason about.
There's a race to replace JWTs with something better (PAST is an example) and
while I don't think the underlying idea behind JWTs is any good either, even
if you disagree, you should still wait for one of the better formats to gain
acceptance.

~~~
everdev
Don't major companies like Google use JWTs?

~~~
tptacek
Major companies like Google do all sorts of dumb things, and, equally
importantly, have gigantic well-funded security teams triple-checking what
they do, so that the pitfalls in these standards are mostly an externality to
them.

(The actual answer is: I have no idea what Google does with JWTs.)

~~~
logicuce
With the right choice of algorithm, and if you control the code which
interprets that JWT (whitelisting the alg and choosing the right library), I
don't see a reason why JWT would be insecure.

~~~
tptacek
It's absolutely true that if you do everything correctly, a JWT implementation
can be secure. Generally, in crypto engineering, we're looking for
constructions that minimize the number of things you need to get right.

~~~
batoure
Yeah this is the problem with crypto security people they are one dimensional.
JWT has the benefit of allowing disconnected services to send each other
information through the front end.

Which minimizess the number of things you need to get right or in your words
equals more secure.

Designing a token that can be validated instead of looked up.
(Design/Implement once)

Or

maintaining, updating and monitoring a set of firewall rules so that app-
servers in network zone x and y can make call backs to a database in network
zone z.(design many implement many)

There are a ton of great reasons to use JWT at scale. As with anything use
case is important.

~~~
tptacek
I disagree almost absolutely with all of this but am comfortable with how
persuasive our respective comments on this thread are or aren't to the rest of
HN. I'd rather not re-make points I've already made.

------
barrystaes
Do everything via HTTPS, disable HTTP. The login request (POST, dont use url
query params) contains username + password. The API replies with a session
token (a random string). You can store any metadata relating to this session
token in your DB.

The API client should this token in every request that requires
authentication, often in the header as `Authorization : Bearer
123TheToken456`.

JWT: If DB performance becomes a problem (or you want to expose signed session
metadata) consider using JWT to provide session validation with the request
itself. The downsides of JWT are that its often used to hold secret values
(dont do this), or is a few kilobytes big which makes all requests slow, or
stupid mistakes in signing and session validation that make it very insecure
like allowing any request to just specify false permissions.

~~~
matwood
I have found the above (sans JWT) to be the simplest, secure method. Do
everything over HTTPS, use basic auth or post for the user/pass and return an
expiring token, use that token as a Bearer token for all subsequent requests.

~~~
oozzee
I’m mostley a FE person at the moment so forgive me for my ignorance but how
does the server use the token passed to the client to do auth?

Does it keep a copy somewhere and check against it on every request?

~~~
pc86
> _Does it keep a copy somewhere and check against it on every request?_

Yes. The last time I did this we checked the X-Token header on every request,
if it didn't exist or there were multiple we replied 401. If only one was
there we checked a DB table of active tokens, if it wasn't there or had
expired we replied 401. If it was there but wasn't associated with a role that
had access to the requested resource, we replied 403. If it was not expired
and had access we continued with the request.

As soon as you get away from "check authentication on every request" your
attack vectors increase. As a bad actor, I no longer need to bypass your
authentication, I just need to bypass whatever system you have in place to
decide whether or not to authenticate me. That's generally going to be easier.

~~~
mring33621
I was planning to use custom headers over HTTPS for a similar thing, but then
I read that some firewalls will strip custom headers, even over HTTPS. Can
anyone with experience comment? Thanks.

~~~
matwood
Just use a Bearer token in the Authorization header from the OAuth spec:
[https://tools.ietf.org/html/rfc6750#section-2.1](https://tools.ietf.org/html/rfc6750#section-2.1)

------
drderidder
I highly recommend reading "The Do's and Don'ts of Client Authentication on
the Web" [1] from MIT. It's rather old and not very well-known, but it's
excellent. The concepts provide very useful background info that will serve
you well no matter what technology you use to implement your HTTP services,
including issues like session hijacking, etc. One of it's best
recommendations: avoid roll-your-own solutions. Secondly, I recommend checking
out the "auth" example from the expressjs repository on github [2]. It will
provide a practical implementation example. Lastly, if you're considering
using Express or any similar framework, I recommend checking out "route
parameter preconditions". These seem to remain a little-known feature of
Express, but they can be particularly useful for applying middleware to entire
sets of routes, for example enforcing authentication on anything under a
certain path. You can still find screen-casts for route-specific middleware
and route parameter preconditions on the Express 2.x documentation site by TJ,
the original author [3]. Some of the specific details may have changed in the
newer versions of Express, but TJ's explanation of the concepts is simple and
clear.

[1]
[https://pdos.csail.mit.edu/papers/webauth:sec10.pdf](https://pdos.csail.mit.edu/papers/webauth:sec10.pdf)
[2]
[https://github.com/expressjs/express/blob/master/examples/au...](https://github.com/expressjs/express/blob/master/examples/auth/index.js)
[3]
[https://expressjs.com/2x/screencasts.html](https://expressjs.com/2x/screencasts.html)

~~~
iopuy
Isn't using the "auth" snippet more an example of rolling your own crypto? Why
not use established libraries like passportjs? Super curious.

~~~
stephengillie
I wrestled with Passport for 3 weekends last October on my side project before
reverting to a simple form for login. Passport has several dependencies that
aren't well-documented, like a SQL ORM. It took a full weekend of researching
to figure out what ORMs were and how they were used, since almost every blog
assumes readers will recognize one in their code. This led to blogs pushing
the opinion that ORMs were pointless and useless unless you already knew SQL.

Then, there are articles like the Hackernoon post explaining why most Passport
blog posts are wrong in one way or another.[0] This article explains that
there are no "copy/paste" authentication solutions for Javascript, as there
are for other languages - and Passport is probably the best out there.

As there's no "copy/paste" auth solution for Javascript, it becomes essential
to understand how auth works with your site. It has to be added to every
Express render call, to work with the Session. And rolling your own is
educational - you can learn some of the common pitfalls and why rolling your
own is a bad idea.

I do plan to go back to Passport sometime this year. The number of Oauth
providers is nearly overwhelming - too much to ignore. But also daunting for
the first-time student.

[0] [https://hackernoon.com/your-node-js-authentication-
tutorial-...](https://hackernoon.com/your-node-js-authentication-tutorial-is-
wrong-f1a3bf831a46)

~~~
matwood
Passport is pretty large so it can be confusing. IMO, it's much easier to not
use the session stuff in passport and just do your own thing letting passport
handle the flow. You can use the BasicAuth strategy on a /login url to sign
someone in and grant a token, and then use Bearer auth strategy to check the
token on the rest of your urls.

Doing it that way, Passport doesn't _require_ an ORM at all. You'll need to
obviously provide a way to auth a user and verify a token, but that's then up
to you.

Now, if you want to actually use OAuth it can get complicated because the
flow.

------
jpalomaki
Why not use either simple API key or HTTP basic auth? Both are simple to
implement and supported by all the tools and libraries.

I would consider more complicated solutions only if you first come to
conclusion that these simple things are not fit for the purpose.

True that some fancy token based solution may reduce database load, but if the
API is doing something useful then that one primary key lookup and potentially
the password hashing won't be a show stopper. Drawback with tokens and
skipping the DB check is that you can't simply kill a client behaving badly.
With API key you can just change the key and requests stop immediately (with
MVP product this might be an issue, since maybe you have decided to add rate
limits etc later).

~~~
comradesmith
HTTP Basic authentication should never be used, it is very vulnerable to
traffic analysis attacks. HTTP Digest authentication however, would be a
perfectly fine solution.

~~~
dozzie
How so? Over SSL? (Note that you should never call anything requiring
authentication/authorization over plain HTTP.)

~~~
comradesmith
A quick Google suggests you're right, as in either case you must run SSL/TLS.

Appypolylogies.

------
Daycrawler
It depends on the use-case.

* Public data API (no notion of user account, e.g. weathers API, newspapers API, GitHub public events, Reddit /r/popular, etc): use an API key. The developers must create an account on your website to create their API key; each API call is accompanied by the API key in the query string (?key=...)

* Self-used API for AJAX (notion of user account, e.g. all the AJAX calls behind the scenes when you use Gmail): use the same user cookie as for the rest of the website. The API is like any other resource on the website except it returns JSON/XML/whatever instead of HTML.

* Internal API for micro-services: API key shared by both ends of the service. There can be a notion of user accounts, but it's a business notion and the user is an argument like any other. If possible, your micro-services shouldn't actually be accessible on the public Internet.

* API with the notion of user accounts intended for third-parties (e.g. Reddit mobile app where the users can authorize the app to use their Reddit account on their behalf): OAuth2

------
6ue7nNMEEbHcM
Hi, can someone explain me why SSL client authentication is not widely used?
You can use the same protocol you use to authenticate hosts to authenticate
users, yet no one seem to do that nowadays. I'm not professional web developer
so maybe answer to this question is obvious (but I just don't know it).

~~~
rkangel
I have worked with systems that use it to authenticate machine to machine
communication (e.g. a web backend authenticating itself to another service
doing work for it). In that environment it works well.

Using it to authenticate a _person_ regardless of device doesn't work so well
from a usability point of view.

~~~
j_s
I've been experimenting with using the server's public SSL key as a client
certificate to authenticate self-hosted and cross-server web service requests
since the cert should be available at runtime in common enterprise setups yet
incentives align to keep it well-secured.

I would appreciate pointers to any open source libraries demonstrating best
practices and/or promoting this approach, specifically protecting against
replay attacks and race conditions that come up as the cert is renewed (much
more often - thanks Let's Encrypt!).

------
scandox
PAST looks good.

[https://github.com/paragonie/past](https://github.com/paragonie/past)

Basically JWT but without the pitfalls as far as I can see.

~~~
j_s
Definitely depends on timeline; PAST is a reasonable recommendation gaining
momentum as best practice. The recent Show HN annoucement discussed many
caveats of authentication tokens:

Show HN: PAST, a secure alternative to JWT |
[https://news.ycombinator.com/item?id=16070394](https://news.ycombinator.com/item?id=16070394)
_(2018Jan:361 points,137 comments)_

------
baddox
I’d say it depends a lot.

If your API just serves public non-user-specific data, a simple API key might
be okay. The obvious downside of this method is that a user leaking their
client API key is a big problem, especially if your users are likely to
distribute code that makes requests (e.g. a mobile app that makes requests to
your API).

The state of the art is probably still OAuth, where clients regularly request
session keys. This means a leaked key probably won’t cause problems for very
long. The obvious downside of this is complexity, but that can be mitigated by
releasing client libraries that smooth over the process.

~~~
fyfy18
One thing to be aware of with OAuth 2.0 is Refresh Tokens. If the spec is
followed, the Refresh Tokens are long-lived and never expire (the spec makes a
suggestion that you revoke used tokens, but it's not required), so if they are
leaked you are in for a bad time.

There's an RFC that goes into some of the security considerations of OAuth
2.0, that should be required reading if you implement it (even from a pre-
built library):
[https://tools.ietf.org/html/rfc6819](https://tools.ietf.org/html/rfc6819)

~~~
Fradow
If the Refresh Tokens are leaked, you revoke them and the user has to re-
authenticate.

It's crucial that clients are able to respond to their refresh tokens being
revoked.

The good thing is that it is a standard workflow, contrary to API key being
revoked, which is generally not handled (most people hard-code API key in
their client).

------
moduspwnens14
AWS has their own v4 signature method that I always thought was neat.

Key benefits:

* Secret not included in request

* Verifies integrity of the message (since its contents are signed)

* Protection against replay attacks

It's probably overkill in a lot of situations, but I've always liked how even
if TLS were compromised, all the attacker would gain is the ability to see the
requests--not modify them or forge new ones.

I haven't used JWT before, but reading one of the links below, it looks like
it covers a lot of the same stuff (although you'd have to implement your own
replay protection if you want that).

------
ivan_ah
One generic solution is to have identity on the server (users table) and
generate one or more tokens for each user. When a user wants to make an
authenticated API call, they have to add the approprite header to their
request:

    
    
        curl -X GET https://127.0.0.1:8000/api/example/ -H 'Authorization: Token 9944b09199c62bcf9418ad846dd0e4bbdfc6ee4b'
    

Note: HTTPS is required for all of this to be secure.

This is what comes out of the box with Django Rest Framework.

------
EngineerBetter
It makes me sad that in 2018 that it is entirely reasonable for such a simple
and common question to elicit so many answers. Of course no one solution fits
all use cases, but skimming the comments there seems to be a very diverse
range of suggestions. Wouldn't it be lovely if there was one stand-out
solution that was so good it was a no-brainer?

FWIW I have ended up using OAuth2 for this situation a few times, and it
always feels more complicated than I'd like.

~~~
liquidise
This is arguably self-serving but I am happy there isn’t one. The appeal to
coding is that it hasn’t matured to being computerized LEGO’s, where I spend
my time connecting prebuilt components unspecialized for my application.

But we are not alone in this regard. Bridge building is centuries more mature
than software engineering and their shapes, materials and construction methods
still change regularly. I would expect to see this trend remain for a long
time. Engineering is an inherently creative practice, often staffed by
appropriately creative people. The continued evolution, including the trial
and error approach, are likely to continue for decades.

~~~
trevor-e
I do agree with your sentiment, but is creativity something we want to
encourage with security? Security is hard, and most developers won't know when
they've made a mistake implementing something. The laws of physics haven't
changed for bridge builders. In the end, everyday consumers are the ones
suffering from the recent hacks.

------
snomad
Auth0 and Okta have tons of docs on this. Even if you don't use their
services, they have much to read.

Also, here is a good recent video for ASP Net Core 2, that includes extra
things like HSTS, etc. Even if your not in ASP, the concepts will be relevant
[https://www.youtube.com/watch?v=z2iCddrJRY8](https://www.youtube.com/watch?v=z2iCddrJRY8)

------
stillbourne
OpenId its an extension of OAuth. OpenID provides "Authentication" while OAuth
or JWT provides "Authorization." But the real question is what language are
you using? If you are using ASP.NET I'd recommend reading this:
[https://docs.microsoft.com/en-us/aspnet/web-
api/overview/sec...](https://docs.microsoft.com/en-us/aspnet/web-
api/overview/security/individual-accounts-in-web-api)

------
dmichulke
If there is nothing special about it, I'd recommend JWT, for the simple reason
that you have less load on your DB (and more on your CPU but that is usually
not the bottleneck)

------
san_at_weblegit
There is no single good answer to this question without taking into account
the security consideration of the API in question and the consumers. On a high
level all solutions work just fine as long as we understand the tradeoff's
involved (cpu, IO, revocation, complexity,..). The different solutions that
could be tried with ease are: 1\. Network filtering - If the API consumers can
be limited by identifying their IP addresses 2\. Bearer tokens - Simple random
string that can be passed in the header (depending on number of consumers,
ability to revoke/change tokens it can become little complex) 3\. JWT's -
Similar to bearer tokens without the ability of revocation and extra cost of
key management and CPU (the signature verifications are quite costly). 4\.
OAuth - Better call it 2-legged OAuth since its between servers only. Its the
ideal one with both revocation possibility and signature verification.

The first three could be implemented easily inhouse and are suited when number
of consumers are small. Its better to use some third party SAAS service or
OAuth server for the fourth one. I work professionally on these things and
these implementations can be time consuming. More than often people dont take
into account their requirements when choosing a solution.

------
simonhamp
If you are looking for something along the lines of OAuth2 - you should BTW!
Highly recommended if your API is going to be consumed by first-party client
apps on different platforms or third-party clients - one of the best setups
I've come across is Laravel Passport[1].

If you don't mind running a PHP application, or it being built in Laravel, (I
don't, but some do) it's actually a really good implementation of a solid
OAuth package[2] (Disclaimer: I am a maintainer on oauth2-server).

You can set this up in a couple of days, and it'll be ready to roll for the
majority of use-cases. With a few simple tweaks and additions, you can have it
doing extra stuff pretty easily.

In one build I'm working on, this acts as just the authentication layer. The
actual API that relies on the tokens this generates sits elsewhere and could
be written in any other language (it's not in this case).

[1]:
[https://github.com/laravel/passport](https://github.com/laravel/passport)
[2]:
[https://github.com/thephpleague/oauth2-server](https://github.com/thephpleague/oauth2-server)

------
LandR
Anyone know amy good resources for the following scenario:

WEB API that a device needs to authenticate to. Can't store password on device
(it's a device we don't control). No user, so authentication has to be all
autommated.

i.e. we need to run software on a clients machine, and it has to authenticate
to our web api to send us data.

We obviously don't want to hard code the credentials in the software as that
can be trivially extracted.

~~~
icebraining
_Can 't store password on device (it's a device we don't control)_

Can you expand on this? Because storing a device-specific password (or api
key, which is essentially the same) would be my first suggestion.

If it's because you can't configure the device, then my suggestion would be to
create a process that embeds the device key into the software before deploying
to each particular device.

~~~
LandR
We need to run software on clients machines, we need this software to be
running as service (no UI). This service needs to communicate back to use
securely via our Web API.

We could have a password entered by our systems guys who deploy to a new
machine for the first time, the service encrypts and stores that on disc, then
each time it wants to talk to us it can decrypt its password.

I'm not sure if that would be a good solution, or is it just as insecure as
having password in the code.

~~~
scriptkiddy
I Found a somewhat interesting solution for this issue. I assume you know what
an ssh public/private key is, correct? Well, apparently, there is a way to
apply this concept of ssh public key authentication to the HTTP protocol.

This technique is referred to as "Mutual Authentication":
[http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLS...](http://www.cafesoft.com/products/cams/ps/docs32/admin/SSLTLSPrimer.html)

Basically, it's 2-way SSL. You use signed SSL certs to authenticate the server
to the client and the client to the server. You could use your own cert
signing server or employ a third party cert signing service.

Using this method, your techs would need to set up the SSL cert for the client
machine when installing the software, or, the SSL setup procedure could be
part of the software installation procedure.

Interesting idea that may solve your problem. Hope this helps.

~~~
newscracker
This brings in the question of how long the client certificate would be valid
for and how it would be renewed before expiry. If sending a tech costs a good
sum of money, one may be tempted to use certificates that are valid for
decades, which may or may not be a good idea depending on the client
environment, advances in cracking some algorithms or proving collisions in
hashing, and business related factors.

~~~
scriptkiddy
Cert renewal can be automated the same way letsencrypt does it for instance.

~~~
icebraining
Let's Encrypt validates during each renewal if the server still controls the
DNS and/or HTTP endpoint. The point of the limited duration is to ensure that
an attacker who got a copy of the certificate, but who doesn't control the DNS
or HTTP endpoint, can't keep using it for long.

In this case, I don't see any automated check that can verify that the client
trying to renew the cert is the original device, so there's no point in
limiting the lifetime of the certificate, unless you send a person to do that
verification manually.

~~~
scriptkiddy
That is an interesting limitation. I'm sure there is some way to get around
it. However, I'm not a network security expert. I just thought using SSL certs
for authentication was an interesting idea.

------
Pigo
Just wanted to throw Azure API Management out there
[https://azure.microsoft.com/en-us/services/api-
management](https://azure.microsoft.com/en-us/services/api-management)

If you happen to be using Azure. I found it very useful for everything you'd
want to do with your API, one of them being able to tie down security as much
or as little as you need. It even builds a front end for anyone who has access
to use for reference. But that's just one of the cool features.

------
vfulco
From the cheap seats (as I am a liberal arts major) and currently an
entrepreneur trying to launch some microservices for my resume editing and
other professional services business using R-project and the plumbing api
creator package. What about a fairly lengthy random password provided to
clients (human beings) they input into the intake form using Typeform, then
the underlying code checks for it in the "authorized" file and removes it
after 1 time use? The form feeds the api inputs directly.

TIA.

------
balls187
Use Auth0

eta: I don't work for them, but really no need to roll your own.

------
jongpieter
Depending on your usecase, a quick setup would be to use
[https://auth0.com/](https://auth0.com/) They have a lot of documentation and
samples to get started.

We have implemented it for authentication with a Asp.Net Core webservice, with
a REST based API. Authorization is also possible, either by working with the
JWT token scopes, or using the Auth0 app_metadata.

------
NicoJuicy
Depends on what you want. You can just use an API key if it's for easy access,
through a header.

If you want more, then use username + pass. Encrypt both or generate something
from both of them. Eg. encrypt(username):encrypt(pass)

If you want more, use private & public keys, which receive a session token the
first time ( when authenticating).

...

I think the end result would be a self hosted oauth server with permission
management.

------
tboyd47
Authentication is such a mess, I don't even know where to begin. Most APIs
rely on some sort of token-based auth, communicated via the header format:
"Authorization: Bearer abc123", as opposed to placing it in the Cookie, as
most web sites will do. Many solutions exist, like OAuth2, JWT, etc. but
that's ultimately what it all boils down to.

~~~
jmulho
Is there any reason to favor bearer tokens over cookies?

~~~
tboyd47
If you use a cookie for an API, it will look like you don't know what you are
doing. Also, there are extra rules around Cookies (expiration, length, etc.)
that may bite you if you use them outside a browser context.

~~~
jmulho
Ah, so there are other contexts (e.g. native mobile apps) that may be sharing
the API, not just browser (web) apps. I think I get it. Thanks.

------
belyakov
If you choose to use JWTs I suggest still keeping a database of tokens and
validate against that. This way you have an option to revoke the token and
force client to get a new one. This is useful for when token data becomes
stale, e.g. email changed, roles added etc. Simply keeping it all in token is
not enough.

------
sidchilling
I think that Auth Tokens are easy to understand, use, and implement. They can
generally be invalidated if the developer feels that they have been
compromised.

Some APIs also use self-invalidating auth tokens based on an expiry date. For
more secure data, I'd prefer that.

------
niwde
Use Access-control-allow-origin and set it to only allow calls from a specific
address.

~~~
ssudaraka
Can someone fake the origin?

~~~
fimdomeio
This is controlled on browser level and most (all?) browsers implement this.
Origin can be faked by just using anything that can make a http request, like
curl. It exists to protect users not the server.

------
darkhorn
Client side SSL certifikate or digest authentication or basic acces
authentication.

------
catchmeifyoucan
Auth Tokens are easy to work with for customers and the API developers.
Generate a token, and then authenticate. I prefer them.

[http://page.rest](http://page.rest) does a good job.

------
Raed667
JWT is pretty easy to understand.

Create a token, put your userId in it, set an expiry date.

If a request comes with a token check if token is valid, check the userId &
expiry date otherwise throw error.

------
tristan_ph
I suggest JSON Web Tokens. Check this out
[https://jwt.io/introduction/](https://jwt.io/introduction/)

~~~
mcny
I would suggest everyone to stay away from jwt unless they're willing to spend
the time to learn how it works.

I believe the meta is that jwt is solid itself but allows doing things
"wrong". Guardrails so to speak are insufficient if not outright lacking.

I'd say just go with plain text token for a web app. I don't like the idea of
trusting the client because I don't understand how jwt works.

~~~
Raed667
Trusting in what sense? If my token only has the userId as data, what kind of
trust is needed?

~~~
mfontani
Some libraries don't make it easy (or possible) to check that the algorithm
used by the JWT sent by the client is in fact the algorithm you're using and
want the client to come back with, see i.e. [https://auth0.com/blog/critical-
vulnerabilities-in-json-web-...](https://auth0.com/blog/critical-
vulnerabilities-in-json-web-token-libraries/)

~~~
Raed667
I see, but sticking to HS256 should solve this without much headache.

------
Chriky
I have an internal REST API (Tomcat server) on a Windows network that uses the
WAFFLE library.

I am interested to know whether HN thinks this is considered secure?

------
sidhuko
For users or applications within your own network?

~~~
somtum
What would you recommend for both?

~~~
sidhuko
For applications using a HMAC token with some sort of timestamp which can be
checked for replay attacks. AWS has a good guide:
[https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthenti...](https://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html).

For users, I'd add a OAuth layer to the application layer and still have this
application using a HMAC like above. You want to try keep things 'stateless'
when it comes to your API's.

------
nautical
OAuth(Robust, Many Libraries), JWT(Easy to understand and implement), API
Keys/Tokens(Simple and fast)

------
intrasight
In addition to token/key, for some APIs in the past I've added IP address
filters.

~~~
newscracker
Using IP address filters would require knowing the client environment and
keeping some kind of planning and communication mechanisms of changes in what.
Big enterprises would have teams and a lead time of a few months to sort this
out, adding more overhead and costs to the service provider (which would have
to somehow be recovered or absorbed).

------
spdionis
Oauth2 tokens or jwt.

~~~
MaxBarraclough
Seems to me the answer is indeed that simple: use OAuth2 and be done.

~~~
sidhuko
So you need to get an access token by validating against a third-party
(keycloak, auth0) to access your own API? That's a pain.

~~~
spdionis
Just use a regular oauth server library in your language/framework of choice.

