CODEWITHSUNDEEP
restrestful-authentication
mcherm
mcherm

Reputation: 24656

REST Authentication: put key in custom header or Authorization header?

I'm designing a REST API framework for a large security-conscious company.

Every caller to our services needs to provide a client key to access the system. We will use that for authorizing access for that particular client as well as rate limiting and monitoring. Also some of our API calls will access customer data, and we will use OAuth 2 tokens to control access to that data.

My question is how to pass the client key. I can not use HTTP Basic Authentication or a query parameter because we cannot pass it in the URI (URIs get logged sometimes) -- it must be in an HTTP header instead. So I have thought of two approaches, both with flaws:

(1) Invent our own header: MyCompanyAPIKey: api-key-goes-here. This is flawed because we will be inventing our own header and that's a poor design choice. It won't work with anyone else or with standard tools (because we invented our own).

(2) Use the Authorization header: Authorization: Bearer api-key-goes-here. This is flawed because it will conflict with OAuth (which needs that header) in the cases where we use that. Technically I suppose we don't need the client key when we have an OAuth token (since the OAuth token was specific to a single client), but I don't know if the normal tools can handle that.

How do you think we should proceed?

Upvotes: 3

Views: 2703

Answers (1)

KTastrophy
KTastrophy

Reputation: 1739

Given your requirements, its sounds like a custom header is the way to go here.

I believe your concern regarding it being a poor design choice is irrelevant here because there is no standardized way of passing an API key. API keys mean different things to different applications. To some, its a user id; to others, its a password; and to others still it's simply means of throttling where no explicit authentication is even required.

As far as compatibility goes, most tools, allow some flexibility regarding working with API so as long is you don't do anything crazy I think you'll be fine. Whatever you do, just make sure that with any standards you do choose to implement that you implement them fully (OAuth vs "OAuth like") and provide documentation.

Upvotes: 2

Related Questions