Implement API keys to authenticate API access?

[MikeTheCanuck]

Ed Borasky asks,

Let me ask a potentially loaded question - given that each project has it's own API container, how would one implement a platform-wide "API key" authentication mechanism? I'm pretty sure Django can manage that sort of thing, but would there need to be coordinated changes to all the API repos or would there be another container just to manage sign-ups and logins?

[MikeTheCanuck]

Nathan Miller responds,

That's a good question. I think it makes sense to use djangos builtin authentication mechanisms. I will look into how they work and if they can be shared between apps.

[MikeTheCanuck]

My questions are:

1. What specific reason would we have for implementing API keys? I know someone will say, "authentication", but really - what are we authenticating and why? Are we intending to restrict access to certain/all APIs just to those who we deem "allowed" to access this data? Or is this somehow meant to achieve "rate limiting", which is merely one implementation of "make the APIs highly available, without allowing one ill-behaved user to monopolize this resource"?
2. If it's the latter - to prevent ill-behaved users from effectively DoS'ing the APIs - or perhaps for cost containment so that any API doesn't end up getting overused to the point that HackOregon gets hit with a huge bill - then before we go hog-wild implementing some technical solution, I feel obligated to figure out the human side of the process first.

Human Problem of API Keys

• enrolment process - how do we bootstrap a new user? Is this a personal request to an inbox, is it "if you have an account then you get a key", or is it "we issue a fresh key to anyone who asks for one"?
• Account setup - we have no account-creation mechanism at the HackO level, and if we went down that path then again we ask, "Do you get an account anytime you like, or do we create them only for vetted parties?"
• Anyone who asks: if anyone who asks gets a key/account, then there will be effectively no anti-abuse controls. Ask anyone who's tried to beat down the trolls - you either hire an army to watch all activity, you invent some cool AI tech that clamps down on new accounts springing up, or you watch new accounts spring up as fast as you disable/shut down the abusive ones.
• Vetted requests: this sounds like the obvious solution, but then again for an organization of sporadic volunteers (with a tiny staff), who has time to be responsible/accountable for this responsibility? What vetting process will they follow?
  • If they really just say, "oh you sent me a nice email, you get a key/account" then we've just wasted valuable time and haven't solved the abuse problem.
  • if there is a vetting process (and some scarce resource that HackO controls, beyond the "public data", that has real consequences if abuse leads to shutoff), then that's a people-process question that ought to be discussed before we create some nightmarish systems issue for an overworked staffer to deal with.

[BrianHGrant]

Let's also be clear if someone is providing their personal information to us for login access we will need to properly encrypt and hold the data, Django's auth is pretty secure but we must then have an update schedule for security releases and the like.

[nam20485]

Specific reason is to disallow people we don't know from using it and to be able to throttle usage from people we authorize.

One way to do this would be to enable Django's builtin token authentication and enable the token authentication view. We then create one user/password combo in each backend, call it 'apiuser'/'apipass' and give that out to anyone who wants to use the API endpoints, including the frontend devs. Once someone asks us to use the endpoint, or the front end devs want to write client code against it, we give these credentials to them, and they use the view to input the credentials and receive the token back, then they can make calls to the endpoints providing the auth token.

This essentially only prevents people we don't know from using the endpoints, but also allows us to use the builtin throttling.

This has the benefit of not having to create or allow creation of accounts, and also to not have to keep user's secrets in our system.

It does not provide a high level of security, but does prevent the random bad actor from abusing our services. (Also it sounds like we don't have the resources or desire to create or maintain a higher level of security so this may be a practical compromise)

[nam20485]

Another alternative, for a more traditional API key approach, would be this: https://github.com/manosim/django-rest-framework-api-key

I see no reason why we couldn't have one key authenticate across multiple backends using this approach.

On Mon, Jun 25, 2018, 4:05 PM Nathan Miller notifications@github.com wrote:

Specific reason is to disallow people we don't know from using it and to be able to throttle usage from people we authorize.

One way to do this would be to enable Django's builtin token authentication and enable the token authentication view. We then create one user/password combo in each backend, call it 'apiuser'/'apipass' and give that out to anyone who wants to use the API endpoints, including the frontend devs.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/hackoregon/civic-devops/issues/198#issuecomment-400123183, or mute the thread https://github.com/notifications/unsubscribe-auth/ABvqFA4RZJkakzjRwQWe_7CcdwPIL1jjks5uAWyrgaJpZM4U29Vy .