Authentication and Authorization uses OAuth2

Why?

The Harmonized Interfaces APIs use the OAuth2 authorization framework to grant you access to metadata, contents and services.

This protocol has the major advantage of separating resource owners (CEN, CENELEC, IEC, ISO) and their servers from the authentication of clients. In the context of harmonizing access, this makes a lot of sense because with a limited number, possibly one single identity, you may be granted accesses to many various services.

Compared to a simpler authentication framework where an identity had to be generated, and managed, for every resource server accessed, this is a huge progress. In addition, security is largely improved do to the temporary nature of access tokens: the same credentials won't be used over extended periods of time.

Unfortunately OAuth2 makes your life a little more complicated. There are utilities however to circumvent this.

In this section we explain the fundamentals. You won't need to use such low-level features but this helps you understand.

Identity and access

Before OAuth2 kicks in, is a process to obtain a pair of API Key and API Secret.

As a human developer of a programmatic client that will consume a service, you will have to register to, usually, a Developer Portal or API Management Platform. An example of such process may include:

1. Sign-up, enter some credentials, create a user profile
2. Find an API, possibly declaring on behalf of whom you intend to consume its services
3. Wait for some clearance process - not all APIs are public!
4. You will then be handed an API Key (a long character token) that uniquely identifies that client of that service. You also receive an API Secret (another long character token)

Notes:

(1) happens only once. The rest is once per service you want to consume.

The credentials in (1) are for human beings, to access your profile. Those in item (4) are for OAuth2 !

Some services offer temporary API Key + Secret, you may have to renew them from time to time.