So I'm trying to secure my web application by using JWT in Scalatra. At the moment I'm using Scentry with both User-Password and RememberMe strategies and my intention is to swap the cookie-based authentication in RememberMe strategy with JWT authentication.
I have found this implementation I can use with json4s (example) but I'm not sure of how to include these features in my code. Can I just simply switch the verifications done with cookies in RememberMe for JWT verifications?
In the same repository, which you have provided there are now code examples. You can check this link.
Related
I am mid-way of implementing oidc/pkce implicit authorization flow in my asp.net core rest web api for a public JS client.
I almost understand how this works, but I can't exacly understand what are the biggest issues with another approach - if I were to use the default cookie (or session) authentication provided by ASP Identity.
I find it hard to google this topic. Can I please ask for some hints / pointers to articles?
Plain cookie authentication is still used, even when you use token based authentication.
After the OpenIDConnect client receives the final tokens, it will by default create a classic session token that contains the user details and claims. Optionally you can also store the ID/Access/Refresh tokens inside this cookie.
The cookie is encrypted so it can't be tampered or hacked.
The benefit of using OpenIDConnect is when you have multiple clients and/or API's involved and you want a standardized way to handle this. Doing the plain cookie approach with many different services is hard to make secure.
I have tried the sample app of Quarkus and JWT Security Sample App
How can I implement JWT refresh token in Quarkus Framework?
You have to options here, which are basically the same, you have to invoke keycloak through the rest api in order to get your refresh token. You can do that by using a rest-client, like in here or an adapter, this are your options with the jwt integration.
If you instead use a different dependency like the oidc client you will be able to create new tokens and have more options, check this guide.
Thanks
I'm currently using auth0-js library v8 to authenticate users against Auth0. This library forcibly signs JWT tokens using RS256. Temporarily, I would like to decode the token and re-encode it using HS256/my current CLIENT SECRET, before returning the token in the authenticated response. Can I use Auth0 rules for that? Any idea how?
Reacting to Pawel's comment up there: this is no longer an issue! With Graphcool resolvers you can now extend your schema to handle authentication (amongst others) whatever way you deem suitable.
We're developing an iOS app, where the user needs to authenticate using email+password (or mobile number). Our backend is made of a couple of microservices using Akka-Http. It needs to be fast, scalable, concurrent, and the authentication+authorization should work across our multiple services.
I'm trying to figure out which authentication method to use.
Akka-HTTP currently offers Basic Auth and a partial implementation of OAuth2.
So at first we were considering Basic authentication (too simple and not enough functionality), Oauth1 (too complex), so we moved towards OAuth-2.0 because it is sort of a standard.
Then we considered AWS Cognito because it combines Oauth-2.0 and OpenID Connect which gives the authentication mechanism that OAuth2 lacks.
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
Then we realised that OAuth2 is just for authentication using a third party - when in fact we don't need a third party authentication provider - maybe we need to do it ourselves, and using Cognito is an overkill that would create extra api calls outside our microservices...
So I read a little bit about creating our own custom auth provider, using WSSE specs:
http://symfony.com/doc/current/cookbook/security/custom_authentication_provider.html
And I also found this example using Spray, but I'm sure it's not that different from Akka-Http:
http://danielasfregola.com/2015/06/29/how-to-create-a-spray-custom-authenticator/
It looks too simplified and doesn't have token expiration...
So my question is, am I missing something? What method should I chose and where can I find examples for it?
I feel like I'm going in circles, we're gonna have to write our own custom authentication provider from scratch, which kinda doesn't make sense. After all almost everybody needs authentication and it should be a standard.
I've recently been using SoftwareMill's akka-http-session library and found it simple and easy to integrate. It has support for case class based sessions, JWTs, refresh tokens with pluggable storage, using headers and CSRF tokens as well as some nice simple directives for use in routes.
My solution for user registration has been to use Keycloak, an open source server which can handle user registration and do OIDC, OAuth2 style login. It reduces the amount of code I have to write, and the code is more secure than if it rolled it myself.
I then write my application as Scala backend that's purely a JSON API and a React/Javascript rich frontend in front of that API. In this configuration the authentication is handled completely on the front-end (and can be done in your iOS client). The front-end app redirects the user to Keycloak and when the user comes back they have a signed "JWT" token you can keep in a cookie.
That JWT token is attached to all API calls made the JSON backend as an Authorization Bearer token HTTP header. The token itself contains the users email address and is cryptographically signed by the Keycloak server.
The backend gets the JWT token in the HTTP header, extracts the email address and verifies the token is cryptographically signed by the keycloak server.
It's performing a certificate check on the keycloak server and can cache it's certificate. So it doesn't need to have roundtrips like OAuth, or any upstream calls to make.
This gives us simple, low-chance-of-failure, high speed authorisation in our JSON backend API and means we aren't putting secrets in the iOS client, or rolling too much of our own code.
I'm trying to implement a full development with REST Spray. There is an argument that I have not yet figured out and I have not found documented: how to protect the routes for authentication / authorization? I would just use a token - based authentication through a header of the request.
At the moment Spray implements only basic security mechanisms. It comes with HTTP basic authentication implemented and some cookie support.
It makes sense not to include more specific security implementations because every project implements it differently. Although Oauth implementation would be useful in many cases. There might be projects that provide that for Spray.
Token based authentication sounds like a good general choice.