Forem: Matthias Biehl

Video Tutorial: How to build Social Login with LinkedIn API, OAuth and Node.js - Part 1

Matthias Biehl — Sun, 14 Jun 2020 14:41:52 +0000

Social Login allows you to improve convenience for your customers and increase conversion rates for your signups and offerings. Instead of letting users fill in forms, they just need to click to sign in with LinkedIn.

In this video I show you how you can develop Social Login with LinkedIn, by leveraging the LinkedIn API and LinkedIn OAuth. We will develop a small program in node.js to see OAuth and APIs in practice.

Don’t miss any upcoming episode and subscribe to the API-University channel on youtube.

This is the first part of a 3 part series on social login:

Social Login Part 1: Write code to call the LinkedIn APIs to get profile and email data.
Social Login Part 2 (publication scheduled for 2020-06-17): Write code for the redirect endpoint and code for getting an access token.
Social Login Part 3 (publication scheduled for 2020-06-24): Write code to push signup information to a mailinglist provider via API.

You might also want to watch: How to use the LinkedIn API and OAuth

In the video, I show you how to write a node.js application to call the LinkedIn APIs. It makes your life much easier because it guides you through the process, and helps you to get all the nitty-gritty details right. Without it, you would probably spend a lot of time reading the documentation or figuring it out by trial and error.

Get the Source Code.

Learn about OAuth in a more structured way, with step-by-step guides:

How to use Google Sheets API

Matthias Biehl — Tue, 26 May 2020 23:47:20 +0000

Learn to use the Google Sheets API. In this week’s episode, I show you hands-on how you can turn any Google Spreadsheet into a data store that is accessible via API.

Don’t miss any upcoming episode and subscribe to the API-University channel on youtube.

In the video, I show you how to use the worksheet as a step-by-step guide. It makes your life much easier because it guides you through the process, and helps you to get all the nitty-gritty details right. Without it, you would probably spend a lot of time reading the documentation or figuring it out by trial and error.

Get the Google Sheets API Worksheet

Learn about APIs in a more structured way, with step-by-step guides:

The 10 most critical API security risks - Part 9: Improper Assets Management

Matthias Biehl — Tue, 24 Mar 2020 20:00:30 +0000

The recently published “OWASP API security top 10” report analyzes the anti-patterns that lead to vulnerabilities and security risks in APIs. In this 10 part series, we introduce these API anti-patterns. Every API professional should know about these anti-patterns.

Improper Assets Management from the OWASP API security paperAPI security anti-pattern for Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.

Want to learn more?

Check out the complete OWASP API security paper. To secure access to your APIs, learn more about the OAuth in the OAuth Book, or the OAuth Course. To provide and use identity data in apps and APIs, learn more about OpenID Connect in the OpenID Connect Book, or the OpenID Connect Course.

The 10 most critical API security risks - Part 8: Injection

Matthias Biehl — Tue, 17 Mar 2020 21:01:26 +0000

Injection from the OWASP API security paperAPI security anti-pattern for Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Want to learn more?

The 10 most critical API security risks - Part 7: Security Misconfiguration

Matthias Biehl — Tue, 03 Mar 2020 17:04:41 +0000

API security anti-pattern for Security Misconfiguration

Security misconfiguration is commonly a result of insecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

The good thing is, that it is relatively easy to fix security misconfiguration and considerably improve the API security as a result.

Want to learn more?

Alexa Account Linking with OAuth and Spotify

Matthias Biehl — Fri, 28 Feb 2020 08:07:18 +0000

We can personalize Alexa Skills by accessing our own APIs or the APIs of third parties from within our Alexa Skill. This allows us to have the customer’s data available in our Skill. For example, if we create a music Skill and can access the user’s Spotify playlists and preferred music, the user will feel at home – like the Skill is personally created for him/her. To realize such a personalized experience we explore the Alexa Account Linking feature with OAuth on the example of Spotify.

Let’s work with our Alexa Skill that needs access to Spotify playlists. The Alexa Skill has the role of an API client accessing the Spotify API. Spotify is the API provider; it provides the playlist data via API and protects the API with OAuth. The OAuth framework is a standardized, commonly used protocol for delegating access rights on the web and in web applications. It is a well-invested time, to learn more about the OAuth protocol.

When an API is protected with OAuth, this means that a valid OAuth access token is required to access the API. In our example, this means that the Alexa Skill needs a valid OAuth access token from Spotify if it wants to access the playlist API. How does it get such a token?

According to the OAuth protocol, the end-user, i.e., Alexa user, has to authenticate with Spotify first, then the client, i.e., Alexa Skill, has to authenticate with Spotify and if all checks are positive, Spotify may hand out the OAuth access token. This OAuth access token created by Spotify is stored in the user context of the Alexa Skill. This OAuth access token allows the Skill to make calls against the Spotify Playlist API in the name of the end-user, without the end-user having to authenticate against Spotify with each API access.

Account linking in Alexa means in more technical terms that an Alexa Skill becomes an OAuth client. This OAuth client can request, hold and use an OAuth token that interacts with the OAuth server according to the standardized OAuth protocol. In the following, we will walk through the steps necessary to get an OAuth token and thus create linked accounts.

There will be a series of posts on this topic:

In my new book “Making Money with Alexa Skills – A Developer’s Guide” I describe not only how to develop, but also how to monetize Alexa Skills. Account linking is one of the possibilities for personalizing a Skill and make it unique – more practical approaches for personalizing Skills are described in the book. In this book, I explain in detail how to make Alexa Account Linking with OAuth and Spotify work.

In the OAuth 2.0 book, you can find a simple and understandable explanation of all the standard OAuth Flows (such as those supported by Alexa). What makes this book unique is that complicated OAuth interactions are visualized as easy-to-understand sequence diagrams.

The 10 most critical API security risks - Part 6: Mass Assignment

Matthias Biehl — Tue, 25 Feb 2020 17:22:53 +0000

Mass Assignment from the OWASP API security paper

API security anti-pattern for Mass Assignment

The binding of client-provided data (e.g., JSON) to data models, without properties filtering based on a whitelist, usually leads to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

Want to learn more?

Is the API-key enough? Common API security issues - and how to fix them.

Matthias Biehl — Tue, 25 Feb 2020 05:52:34 +0000

It can be seen over and over again: API-keys are directly embedded in the source code of an app. The most recent incident as of February 2020 is the Iowa caucus app, that contained API-keys right inside the source code.

But it should be clear, that source code or the corresponding assembly/binary/bytecode is not secure storage for credentials, especially when rolled out to the end-users' device! Hardcoding API credentials into the source code is a no-go. There are at least two reasons:

Source code may be uploaded to a public repository (e.g. GitHub). By the time it is uploaded, the uploader may not be aware of the credentials being included in the sources.
Assembly/binary/bytecode can be easily disassembled/decoded and any API-keys can be easily extracted.

If source code and the resulting assembly/binary/bytecode are not a secure place for API credentials, how should API credentials be persisted instead?
There are several aspects to the answer:

Static credentials such as API-keys should not be used in the first place. Instead, dynamic credentials should be used. This needs to be fixed by the API provider. See section "Static vs Dynamic Credentials".
Where credentials are stored. Not in assembly/binary/bytecode, but in secure storage. This needs to be properly managed by the API consumer. See the section "Credential Storage".

Static vs Dynamic Credentials

API-keys are static credentials and thus can be easily transferred and used in unintended scenarios. They do not even adequately identify the app. And under no circumstances should access to user-data be made, based on an API-key.

This is a problem, that first of all needs to be addressed by the API provider. The API provider needs to offer APIs protected by dynamic credentials. Dynamic credentials, such as OAuth, require to include the end-user in the loop, who has to authenticate. And the end-user should be able to check the trustworthiness/authenticity of the app.

Dynamic credentials typically have several components, (1) identification of the app with a static credential, called clientID and clientSecret in OAuth, and (2) the end-user identification. The static credentials of the app should be stored in secure credential storage, offered by the operating system (see next section). If the end-user also decides to store end-user credentials, they should also be stored in secure credential storage.

If you want to learn more about OAuth, read up in the OAuth Book or in the OAuth Course.

Credential Storage

If the API provider did their homework and protected the APIs with OAuth, it is now the turn of the API consumer to store the necessary credentials appropriately.

Apps should use the secure storage offered by the operating system to store app identifiers/credentials and user identifiers/credentials.
Both iOS and Android have appropriate libraries:

The Keychain service in iOS
The Keystore system on Android, and the Account Manager on Android

I hope to have shown you, more secure alternatives to protect your APIs and how to protect API credentials in your apps. The centerpiece? Use OAuth. Correctly.