Add security to API with JWT

[mdtrooper]

First thing, thanks your project, its awesome.

I am working in a small company (its name is dotGIS ) and we are using Martin for some projects.

We need in the api an authentication method such as JWT because it is a common standard.

We can help your project...personally I want to touch martin code...I found some libraries for JWT in Rust...but I need to check which one is better.

Well. Could I fork Martin and add (as branch) support for JWT?

Regards.

[stepankuzmin]

Hi @mdtrooper!

Thanks for reaching us and sorry for the late response. What is your use case for that? I was thinking about adding some kind of access tokens support e.g. like Mapbox Access tokens.

[mdtrooper]

Yes, yes,it is more or less the similar feature of "mapbox access tokens" or carto api keys.

But JWT is a standard RFC 7519.

[mdtrooper]

Sorry...maybe there was a misunderstanding...Could we start a branch with this feature?

[stepankuzmin]

Sure! it's open-source, so you can fork it and create a PR

[delatitude]

@mdtrooper This would be really helpful. Is there an ETA for this enhancement. Thank you.

[mdtrooper]

Yes, sorry. Maybe 3 months, because the summer starts in Spain.

[delatitude]

@mdtrooper Hi there ! Just wanted to check if there is progress on this feature. Thank you.

[shaunakv1]

Hi @mdtrooper , just saw the PR you created for this: (#190). Nice work! However my 2 cents on the topic is that authentication is subjective and while yes JWTs are quite common, not everyone uses them. I did notice that the PR makes enabling them optional using a startup flag, but I am worried we are adding extra complexity of authentication to an otherwise lightweight API server. Especially just one specific kind of authentication. This can cause bloat in the code base over time, from maintenance POV. Here's a great example of how this can quickly get out of hand:

• Jwt #190 (comment)

My worry is authentication scenarios don't stop there and we will have to keep piling on to the code base, where primary use case is vector tiles. Not authentication.

Ability to add access tokens as @stepankuzmin is a lot more attractive in my mind, as while not authentication, it enables a very common domain specific feature for tile servers.

Also most of the common HTTP proxy servers like Nginx, Apache, envoy etc., have modules to enable JWT on a proxy end point that can be wrapped around Martin. That is actually how we use it currently, to enable things like http caching and SSL. No reason why JWT can't be done the same way and kept out of Martin's code base.

That being said, I don't mean to be a party pooper and there is some great work in the PR! If we do end up merging the PR into Martin, I think it would be great to have some examples for people that do want to use JWT on how exactly to setup some scenarios. Right now the readme is updated to saw what options are supported, but I don't believe that is enough for a lot of folks, especially coming from GIS background and not web developers.

[PawelBaranowski]

Hi @shaunakv1, you're probably right that my comment could lead to abusing an otherwise simple functionality.

My use case is much closer to Mapbox Access tokens to which @stepankuzmin has already referred. When it comes to JWT authentication only I second your suggestion about using a reverse proxy. I wonder if we can to the same for access restricion? Could a reverse proxy (or API gateway if more customization is needed) impose some additional filters on table or function sources? If so, I'd like to give it a shot and would gladly create a wiki page explaining the process.

[gbip]

I agree with @shaunakv1 that authentication does not belong in this project 👍

I have been using nginx as a reverse proxy in front of Martin and there is a trick to add an authentication layer !
There is a directive called auth_request that allows you to forward the request to an other server for validation before it is passed to martin.

You could then implement JWT validation in this server (this is exactly what I am doing).

Here is a small snippet :

upstream tile_auth {
    server my_auth_service:443;
}

upstream martin {
    server martin:3000;
}

location ~ /rpc/.+/[0-9]+/[0-9]+/[0-9]+.pbf {
        auth_request /auth;
        proxy_pass        http://martin;
        proxy_hide_header 'Access-Control-Allow-Origin';
        add_header 'Access-Control-Allow-Origin' '*' always;
        add_header 'Access-Control-Allow-Methods' 'GET, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'Authorization';
    }
 
location = /auth {
        internal;
        proxy_pass http://tile_auth/api/check$request_uri;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
        proxy_set_header Host "https://my_auth_micro_service.example;
    }

Nginx documentation about this feature

[saosebastiao]

I'd like to point out the authentication system that is used by Postgrest, another awesome Postgres No-Code server.

https://postgrest.org/en/stable/auth.html

Basically, you have a specialized authenticator user with login privileges and the job of the authenticator is to authenticate the user, extract the user from the JWT, and then run the query after switching to that role.

The cool thing about this is that you get to piggyback on Postgres' extremely fine grained permissions model, allowing you to implement column level as well as row level security. That would be a huge benefit for something like this, and you don't need to implement the row/column level security yourself, just the authenticator system.