Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What do you use for authentication and authorization?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 247 posts

Re: Ask HN: What do you use for authentication and authorization?

#11

Post by atonse »

arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

Also (separate post for separate replies), why not use CORS? this is the first I'm hearing about this. SPA websites often use things like JWT and CORS (ours included)

Re: Ask HN: What do you use for authentication and authorization?

#12

Post by aeleos »

arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

Re: Ask HN: What do you use for authentication and authorization?

#13

Post by nates »

closeparen wrote: post #7

Healthcare is a dangerous sector for a security novice. Please make sure you are familiar with HIPAA [0], including your obligations when handling health information and the nature of possible sanctions. Handling health data at all is risky. Sharing it with partners is something you probably shouldn't even consider before you can afford a serious legal team. OpenID is a mechanism for one website to assert a user's id…

Makes sense. I am sure I misworded, and got turned around a bit. Much of the documentation with fhir talks about oidc. Which seems to be in place if you are doing much more sharing of your data. These things as you mention are probably beyond what is necessary initially and could be added at a further date. However using a service or an open source project that can allow to scale to that size is an interesting proposition.

Re: Ask HN: What do you use for authentication and authorization?

#14

Post by exabrial »

U2F + a password or biometric.

What I wish is Apple and co would give the consumer choices. I am a low threat target; I don't need to enter a pw to unlock the SIP. So presenting a fingerprint + a hardware key would be a huge security improvement and a reasonable defense against 99.9999999% of the threats I face. Unfortunately, Apple assumes we're all being targeting by physical attacks from the NSA, decreasing my convenience level for a non-existant threat.

Re: Ask HN: What do you use for authentication and authorization?

#15

Post by aeleos »

nates wrote: post #13
closeparen wrote: post #7

Healthcare is a dangerous sector for a security novice. Please make sure you are familiar with HIPAA [0], including your obligations when handling health information and the nature of possible sanctions. Handling health data at all is risky. Sharing it with partners is something you probably shouldn't even consider before you can afford a serious legal team. OpenID is a mechanism for one website to assert a user's id…

Makes sense. I am sure I misworded, and got turned around a bit. Much of the documentation with fhir talks about oidc. Which seems to be in place if you are doing much more sharing of your data. These things as you mention are probably beyond what is necessary initially and could be added at a further date. However using a service or an open source project that can allow to scale to that size is an interesting propos…

If you are handling any kind of medical data about people, then you cannot think about security at a future date and your life will be difficult from the start.

Re: Ask HN: What do you use for authentication and authorization?

#16

Post by nates »

aeleos wrote: post #15
nates wrote: post #13

Earlier quoted context omitted.

Makes sense. I am sure I misworded, and got turned around a bit. Much of the documentation with fhir talks about oidc. Which seems to be in place if you are doing much more sharing of your data. These things as you mention are probably beyond what is necessary initially and could be added at a further date. However using a service or an open source project that can allow to scale to that size is an interesting propos…

If you are handling any kind of medical data about people, then you cannot think about security at a future date and your life will be difficult from the start.

Did I say security? I said sharing at a future date.

Re: Ask HN: What do you use for authentication and authorization?

#18

Post by mcbits »

aeleos wrote: post #12
arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

JWT is fine if "revoke" isn't in your vocabulary for the service. If you do need to revoke tokens, JWT becomes a racey contraption that requires synchronizing and looking up state on every request, the avoidance of which was the main reason to use JWT in the first place.

Re: Ask HN: What do you use for authentication and authorization?

#19

Post by throwawaymath »

atonse wrote: post #9
arkadiyt wrote: post #4

Hard to say without more concrete details, but if I had to reply in broad strokes: - For web, user/pass login exchanged for plain session cookies. Should be marked httpOnly/Secure, and bonus points for SameSite and __Host prefix [1] - For web, deploy a preloaded Strict-Transport-Security header [2] - For api clients, use a bearer token. Enforce TLS (either don't listen on port 80, or if someone makes a request over p…

Isn't the argument against JWT mainly one against using it with weak algorithms, and not something inherent to JWT itself?

No, there are several common arguments against JWT for session tokens. The major one intrinsic to JWT is that it has no system of revocation. Thus instead of using a turnkey solution you need to add an additional layer of state logic to your authentication code if you want to be able to revoke tokens.

It is also correct that JWT 1) supports far more cryptography than is necessary; and 2) supports weak cryptography. You can do better than JWT for session management security and performance merely by generating pseudorandom tokens, associating them to sessions and performing lookups.

More generally speaking: signed, stateless tokens are attractive for a variety of technical reasons. They have legitimate uses. But it's typically a poor security decision to choose them in lieu of revocation, for reasons which are mostly uncontroversial among those who work in security.

Re: Ask HN: What do you use for authentication and authorization?

#20

Post by kc10 »

mcbits wrote: post #18
aeleos wrote: post #12

Earlier quoted context omitted.

Isn't JWT also a type of bearer token? Could you please provide some more detailed arguments about why JWT shouldn't be used other than linking its wikipedia article?

JWT is fine if "revoke" isn't in your vocabulary for the service. If you do need to revoke tokens, JWT becomes a racey contraption that requires synchronizing and looking up state on every request, the avoidance of which was the main reason to use JWT in the first place.

It's a common practice to add expiry timestamp for such tokens so each token will expire after certain interval.
Post reply on HN