Secure authentication and authorization are foundational pillars of any successful software project. While comparing APIs to tourism might seem like a stretch, there are some interesting similarities in how a government streamlines the ability to travel between countries and how software engineers enable data to travel between different systems.

This article aims to reveal the philosophy behind many popular authentication & authorization choices, but more importantly it explores how the evolution of standards make the process of sharing digital identity easier for all of us to navigate.

The United World Tourism Organization's Tourism Visa Openness Report found that when a country loosened its Visa restrictions, it benefited economically from increased tourism dollars spent by affluent travelers. The report states that when more barriers to entry existed, 'potential travelers were deterred from making a particular journey and chose an alternative destination with less hassle'.

In tourism or tech people take the path of least resistance

User Experience

When building on-boarding flows for new users of a web application, it's important to consider what is the specific path of least resistance. This often comes down to deciding between 'Single Sign On' (SSO) or the traditional email/password sign up combination which depends on the industry. Dropbox on-boarding / authentication flowFor an organisation-centric app like Dropbox, Sign up with Google indicates they see value in targeting users and groups already using G Suite.

Just like governments deciding who their tourism allies are, businesses must weigh the decision of who they integrate with carefully. The right partnership choices can build immediate trust with potential users, just like strategic visa partnerships influence potential travelers.

Shopify shows their deep understanding of this concept by only offering authentication integrations with well known SSO providers that require an existing payment method to be attached. This means less known merchant sellers piggyback on the trust already established by potential customers with companies such as PayPal, Google, and Amazon.

Countries and businesses clearly benefit economically from enabling users to seamlessly travel through their systems in higher numbers. Though, there is another unseen benefit from these types of partnerships: Data sharing.

The U.S. first piloted the Visa Waiver Program as a diplomacy effort to ease the authentication of travelers among countries friendly with the US. However, after 9/11 it evolved as an authorization agreement to share terrorism data between the participating nations intelligence agencies.

The report mentioned this data included - but was not limited to - previous travel, biographical data, biometric data.

When this lens is put back on software authentication, it is strikingly similar to the challenges that programmers face all the time in authenticating identity, and authorizing data transfer.

Luckily for us civilians, some great minds have been working on this problem for a long time in the global open source software community.

In 2001 an XML framework called SAML was created for exchanging authentication and authorization information. This laid the groundwork for the following era of dot-com engineers who contributed to the idea of digital identity standards, ultimately paving the way for the initial Open Authorization specification release, aka OAuth.

After years of OAuth being in the wild, engineers, corporations, and open source working groups took the lessons learned from the OAuth1 protocol and developed OAuth 2.0, which focuses strictly on the authorization of data sharing between digital systems.

The OpenID Connect specification also evolved in parallel for years. Collaboration and adoption from business such as AOL, Microsoft, PayPal, Google, and IBM ultimately positioned it as the de facto partner of OAuth2.0 as it solves the different problem of authentication between digital systems.

OpenID Connect & OAuth2.0

This pair of specifications outlines the digital contract which is the foundation for securely logging users in, and transferring their data between systems.

• OpenID Connect handles authentication of user's through id_tokens
• OAuth2.0 handles authorization of data transfer though access_tokens

Standardizations in how we access APIs lowers the cost and maintenance associated with projects that can often become quite complex and costly. People love to take the path of least resistance

ID Token's contain who you are (Authentication)

{ 
  "iss": "http://serknight.com", 
  "sub": "camelot|123456", 
  "aud": "1234abcdef", 
  "exp": 1311281970, 
  "iat": 1311280970, 
  "name": "Jane Doe", 
  "given_name": "Jane", 
  "family_name": "Doe"
}

Access Token's contain what you can do (Authorization)

{
  "iss": "https://serknight.com/",
  "sub": "camelot|123456",
  "aud": [
    "https://serknight.com/health-api",
    "https://serknight.com/userinfo"
  ],
  "azp": "my_client_id",
  "exp": 1311281970,
  "iat": 1311280970,
  "scope": "openid profile read:patients read:admin"
}

Everyone prospers when more people can build secure integrations between their system's most valuable data.

However, opening a product's core functionality to standardized authorization like OAuth2.0 does bring other challenging consequences around data security even when using the best in class tools.

A Human Problem

Above all, I find it important to take off the software colored glasses once in a while and discuss what is often pitted as an engineering problem to what it actually is: A human problem.

Software technology has no doubt layered in great complexity to how humans communicate, but it is because of open source software that we continue to progress on the shoulders of giants and humanities internet communication systems are much better off because of it.

If you are ready to set the groundwork to supercharge your product's digital identity layer, part two will dig into the code required integrate an OAuth2.0 and OpenID Connect system.