Lesson 

1  of  7
Introduction to authentication

Authentication is the process of validating identity. Authentication allows a system to confirm

that a user, group, service, or role (known as principal identities) is in fact exactly who they
claim to be and should be allowed to connect to the system. For remote IoT devices to connect
securely, authentication ensures that the device belongs to the infrastructure and is allowed to
connect to the network.

Authentication requires the presentation of credentials (a unique combination of information) in

order to ensure the authenticity of the credentials being given: a user name, password, or
certificate. Much the same way that a passport presents your identity using multiple identifiers:
your photo, your name, the number on the passport, and the country that issued the passport. 

IoT device credentials

Each IoT device requires credentials to access the AWS IoT message broker or AWS IoT Device
Shadow service. These device credentials must be unique per device. All traffic to and from
AWS IoT is encrypted over Transport Layer Security (TLS) so that data is sent securely to the
message broker. The AWS IoT message broker assists with client to AWS IoT communication
and will be described in further detail later in this course. 

Next, let's review what type of identity principals AWS IoT supports.

IoT devices support multiple identity principals for

authentication:
  X.509 certificates
 AWS Identity and Access Management (IAM) users and roles
 Amazon Cognito identities
 Federated users
 Custom authentication 

These identities can be used with mobile applications, web applications, or desktop applications.
They can even be entered by a user when working at the command line.

Each type of interaction, IoT device, mobile application, web and desktop applications, and
AWS CLI commands, typically use different identity principals for authentication. Flip through
the flashcards to see which commonly used identity principal is used with each user/machine
interaction.

AWS IoT devices

Use X.509 certificates, or they can use custom authentication. 

Mobile applications
Use Amazon Cognito identities.

Amazon Cognito provides authentication, authorization, and user management for your
web and mobile apps. 

Web and desktop applications

Use IAM or federated users or Amazon Cognito identities.

AWS CLI commands

Use IAM (identity and access management)
Now that we've listed the four identity prinicpals, let's start with certificates and take a
deeper look into what they are and how they're used.
Lesson 2  of  7
Digital certificates

Digital certificates are electronic credentials used to prove the identity of a user, computer,
company, service, or other network objects. A digital certificate proves identity in much the
same way as a passport, driver's license, or corporate badge. To obtain a passport, you must
present yourself and prove your identity, country of birth, and address. Other countries trust your
passport because they trust the country that issued your passport. 

In security, the country that issues your passport would be called a Certificate Authority (CA).
Certificate Authorities are third party trusted entities that issue digital certificates. Their job is to
verify that the person/company requesting a certificate is who they say they are, much the same
way a government would verify your credentials before issuing a passport.

Public key infrastructure and X.509 certificates

In a public key infrastructure (PKI), both a public and a private key are created. The private key
is retained by the owner of the certificate and is kept secret, whereas the public key is embedded
in the certificate. For digital signatures, any data sent from the certificate holder and encrypted
with the private key can be decrypted by any trusted entity using the public key. For encryption,
the data would be encrypted with the public key and decrypted by the recipient with their private
key. 

X.509 PKI defines the standards for public key certificates and how these certificates attach a
public key to a person, computer, or organization. Let's see what X.509 certificates can do.
More about X.509 certificates
 1
X.509 is a standard that defines the specific format of public key certificates.
 2
X.509 certificates are used to associate a public key with an identity contained within a
certificate. 
 3
AWS IoT authenticates X.509 certificates using the Transport Layer Security (TLS) protocol’s
client authentication mode.
 4
X.509 allows for fine-grained management and certificate revocation.

Attaching certificates
Each IoT device, or thing, requires its own unique certificate. The per-device method of
attaching a policy to a certificate, and then to a thing, is time consuming and makes it difficult to
quickly update or change policies across a fleet of devices. To better manage device things, it is a
best practice to use thing groups.  Using thing groups enables you to aggregate like-type devices
into groups for easy policy application and management. 

Attaching and detaching policies to groups can enhance the security of your AWS IoT
operations. These policies can use policy variables to avoid over-privileged devices and to adjust
permissions of each device in a group according to its unique needs. Having a policy attached to
the thing's group saves steps when it is time to rotate the certificates on an individual thing.
Policies are dynamically applied to things when they change group membership, so you aren't
required to re-create a complex set of permissions each time a device changes membership in a
group.
X.509 policy variables
Use policy variables to write AWS IoT policies that grant permissions based on X.509
certificate attributes or thing properties such as names, types, and attributes. To learn
more, choose X.509 policy variables.
X.509 VARIABLES
https://docs.aws.amazon.com/iot/latest/developerguide/cert-policy-variables.html

Thing group fun facts:

 1
Thing groups enable you to organize your things into a logical hierarchy.
 2
You can add a thing to 10 thing groups.
 3
Thing groups cannot be renamed.
 4
Child things inherit attributes from parent.
 5
You can search device registry and device shadow for attributes.
 6
You can apply updates to thing groups.
 7
Thing group updates can be made over-the-air (OTA).

Defining over-the-air updates   

Over-the-air (OTA) updates enable you to update an IoT device's firmware, software, or
configuration settings remotely. It is a core part of the IoT architecture and helps manage and
maintain devices that could not otherwise be physically accessed for update and security
patching. OTA updates streamline the lifecycle management of the certificates.
Keep certificates updated with OTA updates
–

Use OTA updates to deploy files to one or more devices in your fleet. Although OTA
updates were designed to update device firmware, you can use them to send any file to
one or more devices registered with AWS IoT.
OTA security
–

It is a best practice to digitally sign OTA updates so that the devices receiving the files
can verify that they have not been tampered with en route. You can use Code Signing
for AWS IoT to sign your files, or you can sign your files with your own code-signing
tools.
OTA Update Manager
–

When you create an OTA update, the OTA Update Manager service creates an AWS IoT
job to notify your devices that an update is available. The OTA demo application runs on
your device and creates a task that subscribes to notification topics for AWS IoT jobs
and listens for update messages. The OTA Update Manager is only available with
FreeRTOS.
Amazon FreeRTOS OTA
–

Amazon FreeRTOS OTA updates enable you to:

 Digitally sign and encrypt firmware before deployment.

 Add new firmware images to a single device, a group of devices, or
your entire fleet.
 Deploy firmware to devices as they are added to groups, reset, or
reprovisioned.
 Verify the authenticity and integrity of new firmware after it's
deployed to devices.
 Monitor the progress of a deployment.
 Debug a failed deployment.

Digital certificate lifecycle management

Certificate lifecycle management revolves around the registration, monitoring, rotation, and
deprecation of certificates assigned to your IoT fleet. Certificates have a limited period of
validity. Upon creation, a certificate is assigned an expiration date. For device continuity and
security, you want to rotate your certificates before the certificates expire. Also, if the device
exhibits atypical behavior and investigation determines it is compromised with malware that
compromised the certificate or key, then the certificate needs to be revoked. Each device in your
fleet should have its own unique certificate that contains a unique public key. Do not use one
certificate on multiple devices, because if an unauthorized user gets possession of shared
credentials, they can spoof all the associated devices, feeding unwanted data to the IoT solution
through MQTT topics.

A typical certificate lifecycle:

 1. Generation - Creation of the certificates 
2. Distribution - Assigning certificates to devices
3. Rotation - Periodically changing out the certificates for new ones
4. Revocation  - To revoke or remove a certificate permanently

What's next?
We've defined certificates, thing groups, OTA updates, and how AWS IoT Core supports both
certificate-based authentication (x.509 CA authorized) and custom authorizers (self-signed) to
authenticate requests.

Next, we will discuss identities and how devices, users, and applications can present different
identities to AWS using federated users and Amazon Cognito.

Lesson 3  of  7
Identity providers and federated users

An identity provider (IdP) is a repository that holds user identities. The IdP can be internal to
AWS, such as an IAM identity provider, or an external IdP, such as Facebook or Google. 

To help users authenticate easily and securely, AWS enables users to bring their own identities to
the AWS Cloud. For example, you can authenticate users for your own applications using social
identity providers, such as Facebook and Amazon. You can also enable developers and AWS
administrators to access their AWS accounts using their existing corporate credentials. These
existing external identifiers, known as federated users, can be granted temporary keys to access
internal AWS resources. 

Federation enables you to manage access to your AWS Cloud resources centrally. You can use
single sign-on (SSO) to access AWS accounts using credentials from your corporate directory.
Federation uses open standards, such as Security Assertion Markup Language 2.0 (SAML), to
exchange identity and security information between an IdP and an application.
Benefits of a federated user
 1
You don't need to create custom sign-in code or manage your own identities.
 2
Application users sign in using a well-known external IdP:  Amazon, Facebook, Google, or any
other OpenID Connect (OIDC)-compatible IdP.
 3
Users receive an authentication token. The token is then exchanged for temporary security
credentials in AWS that map to an IAM role with permissions to the AWS resources. 
 4
An IdP helps keep your AWS account secure because you don't embed and distribute long-term
security credentials with your application.
For most scenarios, AWS recommends that you use Amazon Cognito because it acts as an
identity broker and does much of the federation work for you. Let's explore what Amazon
Cognito does and how you can benefit from using it.

Amazon Cognito 
Amazon Cognito is an identity and data synchronization service. The service provides
authentication, authorization, and user management for your web and mobile apps. Your users
can sign in directly with a user name and password, or through a third party, such as Facebook,
Amazon, or Google. 

The two main components of Amazon Cognito are user pools and identity pools. Let's explore
these components and how they interact.
User pools
–
A user pool is a user directory within Amazon Cognito. With a user pool, your users can
sign in to web or mobile apps through Amazon Cognito. Your users can also sign in
through social identity providers such as Facebook or Amazon, and through SAML
identity providers. Whether your users sign in directly or through a third party, all
members of the user pool have a directory profile that you can access through an SDK.

User pools provide:

 Sign-up and sign-in services
 A built-in, customizable web UI to sign in users
 Social sign-in with Facebook, Google, and Login with Amazon, in
addition to sign-in with SAML identity providers from your user pool
 User directory management and user profiles
 Security features, such as multi-factor authentication (MFA), check for
compromised credentials, account takeover protection, and phone and
email verification
 Customized workflows and user migration through AWS Lambda
triggers

Identity pools
–

Use identity pools to create unique identities and assign permissions for users. Your
identity pool can include:
 Users in an Amazon Cognito user pool
 Users who authenticate with external identity providers, such as
Facebook, Google, or a SAML-based identity provider
 Users authenticated through your own existing authentication process
With an identity pool, you can obtain temporary AWS credentials with permissions you
define to directly access other AWS services or to access resources through Amazon API
Gateway.
IAM role usage
–

IAM roles work like this: 

When a user logs in to your application, Amazon Cognito generates temporary AWS
credentials for the user. These temporary credentials are associated with a specific IAM
role. The IAM role lets you define a set of permissions to access your AWS resources.
You can specify default IAM roles for authenticated and unauthenticated users. 

By default, the Amazon Cognito console creates IAM roles that provide access to
Amazon Mobile Analytics and to Amazon Cognito Sync. Alternatively, you can choose to
use existing IAM roles.
How it works:

The goal is to authenticate your user and then grant your user access to another AWS service. 

1. Your application user signs in through a user pool and receives user pool tokens after a

successful authentication.

2. Your application exchanges the user pool tokens for AWS credentials through an identity

pool.

3. Your applicaion user can use the AWS credentials to access other AWS services, such as

Amazon S3 or AWS IoT.

This process uses MQTT over WebSockets, which enables the browser to use all MQTT

features.
Amazon Cognito
Amazon Cognito Developer Guide, tutorials, and use cases.
DEVELOPER GUIDE
https://docs.aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html
Lesson 4  of  7
Demo
Associate an IoT thing with a certificate
In this demonstration, you learn how to create an IoT thing, generate a certificate, and associate
the IoT thing with the certificate.
START 

Video Saved
Lesson 5  of  7
Best practices
As with all technology, best practices may change as the technology changes. When
periodically reviewing your security designs, check the current version of best practices
to ensure that your security goals and practices remain current.
 1
Assign unique identities to all devices and on-premises or in-cloud systems of your IoT
infrastructures.
 2
Assign unique and cryptographic credentials, such as X.509 certificates, to each identity.
 3
Create mechanisms to facilitate the generation, distribution, rotation, and revocation of
credentials.
 4
Create mechanisms to assess the credentials and permissions of your IoT infrastructure
periodically and when their associated identities transition through lifecycle events.
Lesson 6 of 7
Knowledge check
Answer the following question to check what you've learned.
START QUIZ