Tag Archives: api

Posted on
by

I’ve previously written about how Known has built in support for OAuth2 and Open ID connect (both as a client and as a server). Well, over the past few weeks I’ve been doing some work to make this even more useful.

So, I thought I’d quickly jot down some notes as to what you can do with this functionality, and why you might find it cool.

Turn your Known site into an identity provider

The first thing you can do is use the OAuth2 server built in to Known to turn your site into an identity provider.

This means you will be able to create “apps”, allowing users on your site to be able to use third party applications and apps to make authenticated API calls.

It also means you can easily create a “login with” button, allowing your users to log into other sites using their Known profile on your site.

Connect your Known site to an identity provider

The next thing you can do is connect your site to another third party IDP using OAuth2, and allow those users to log in to your site.

This third party IDP could be your organisation’s single sign on service, a third party one, or another Known site.

If the IDP you’re connecting to supports OpenID connect, you can also enable the Federation feature.

What this does is let users with a valid OpenID Token retrieved from the IDP to make authenticated API calls on any Known sites that share that IDP, regardless of whether the user has used that site before.

Primarily, this functionality is designed for a modern micro service architecture world – so for example, you might have a React front end that needs to talk to one or more data sources over GraphQL, including getting blog data from a Known site. All of these services live in different containers, in distributed locations, with different local databases.

But…

Federation…

Something I’ve been pondering recently is whether this functionality might be able to let you do something pretty neat.

Consider, a Known site can be both a client and a server, and both issue and receive public key signed and verifiable OpenID Connect tokens for their users.

Each token knows where it comes from and can state who issued it.

This raises the possibility of being able to establish reciprocal links between sites – each Known (or other site – it’s an open protocol after all) could be both a client and server of each other.

With a bit of UX massaging, this could potentially let the users of each of these sites flow between each site in the network, and getting all the functionality of the local users.

Sure I’m not the first to be thinking this way, but it’s something to play with, and certainly will work a lot more seamlessly than the previously mooted PGP signed login (although I still think that’s pretty cool).

Posted on
by

Just a quick one, you’ve been coding up your REST api, and are trying to use a Bearer authorization token (as obtained from an OAuth2 handshake), and it’s just not working.

If you send your access token as a GET or POST value things work fine however.

You point your head at httpbin.org and to see what your client is sending, and low and behold, the bearer token is present and correct.

You scratch your head and dump the contents of $_SERVER to a log, and to your surprise, nothing. No Authorization header is present!

To save you many a frustrating hour, here’s the answer. Turns out that Apache will strip any authorisation header it doesn’t recognise, which is basically anything that’s not basic auth.

So, you need to put it back in yourself. Do so by putting the following into your .htaccess

RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

Posted on
by

As part of (one of) my day jobs, I have had to yet again bash together a set of REST APIs. This is so we can start wiring up some proper micro services AWS style scalable architecture into the monolithic beast that is the current incarnation of the software I’m working on.

Anyway, here are a few gotchas for this if you intend to start using proper REST style HTTP verbs (PUT/PATCH/DELETE), rather than doing everything via GET and POST like most everyone.

No easy way to access variables

If you’re familiar with the standard $_POST mechanism to access passed variables, you’ll be disappointed that PHP doesn’t by default provide a nice way of access these for PUT and PATCH.

So, you’re going to have to extract them yourself. Not overly tricky, but irritating:

So, for example:

parse_str(file_get_contents('php://input'), $patch);
if (is_array($patch)) {
  $this->data = array_merge($this->data, $patch);
}

Requests not coming through

If you find that your APIs work fine on your local machine but break when deployed, you might want to check your server configuration.

It is quite common for web servers (especially on shared hosts) to block access to HTTP verbs other than most common GET and POST. Modsecurity’s default config definitely blocks these methods.

You should also check that any proxies or load balancers that you have in front of your REST endpoint. These may need some configuration tweaks as well.

Hopefully this will save you some time and frustration!