Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

something something jwt token for implicit flow OAuth I'd guess.


Should be pkce now. I think implicit flow is entirely dead? But could be wrong.


The important thing with PKCE is that it's not completely secure, either. A malicious actor can create an app that uses your client_id and its own code_challenge and verifier. In the event that there are any issues with redirect jacking, such as may be the case with custom schemes on mobile, you're hosed. The only way around this is to use intents (on Android) and OS pinning in the client configuration of your authorization server.


> redirect jacking, such as may be the case with custom schemes on mobile, you're hosed.

How is this possible, any examples?

> intents (on Android) and OS pinning in the client configuration of your authorization server.

Can you please elaborate?


Another option is pkce spa, if they did not do 'auth' checks that the jwt token was indeed signed by auth0 or similar, a carefully crafted js alteration would let you take control of the front end. Then you could give it a incorrectly signed token with all the correct details for another user. Usually they would only use the email for matching which makes things even more trivial.

You would hope they verified the signing of the jwt token on the backend, but seems thats too difficult for many dev's.


PKCE should only be necessary if you're using app linking or have some client app in-between. If you completely trust the server than implicit is fine.


No. This is wrong. Implicit is deprecated in favor of authorization_code + PKCE


it should be but auth0 was not forcing it to be off, just highly suggesting to turn off that 'feature' unsure now.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: