CIAM Discovery Kit (Part 2)
In an interesting turn of events, the last few days of 2023 are bearing witness to something of a radical change in my personal life!… Read More »CIAM Discovery Kit (Part 2)
In an interesting turn of events, the last few days of 2023 are bearing witness to something of a radical change in my personal life!… Read More »CIAM Discovery Kit (Part 2)
As my last event of 2023, I recently got the opportunity to attended the in-person leg of React Day Berlin. As a Principal Developer Advocate… Read More »React Day Berlin: an inaugural outing for Discovery!
Recently, one of my colleagues invited me to an AWS live stream talk she was giving about building secure GraphQL APIs, using Auth0. She’s been… Read More »Discover secure access for GraphQL APIs: an AWS live-stream
As I write this, and for folks who celebrate it, that one particular day in the Christian calendar has once again come and gone. And… Read More »CIAM Discovery Kit (Part 1)
Welcome to my CIAM Discovery blog! My name’s Peter, and this is my inaugural post ? For those of you who may have read my… Read More »Discovering CIAM
Hi 👋 I’m an Identity and Access Management specialist and ex Principal Developer Advocate at Auth0 by Okta. As an Innovator, Architect, Consultant and Engineer, I have have more than 30 years of experience designing and developing secure and robust software solutions. And when I’m not helping folks with the complexities of Customer Identity, you can usually find me working behind the scenes, acting in or directing a show at my local theatre.
SSO is short for Single Sign On – a term typically used for the mechanism where an existing authenticated user session can be used to mitigate interactive first-factor authentication. SSO not only provides ease of use but also facilitates consistency when it comes to user profile creation and management.
Read more about SSO and the value it provides at: a0.to/do/sso
B2B2C stands for Business-to-Business-to-Consumer and refers to the business model where two businesses provide complementary goods or services to reach the same end consumer. In eCommerce, B2B2C typically refers to companies that leverage the online products and/or services provided by other organisations, adding complementary value that is delivered to mutual customers directly via the internet.
B2B – better known as Business-to-Business – refers to the process of businesses selling products and services directly to other businesses rather than selling directly to consumers. In eCommerce terms, B2B typically refers to organisations that leverage the online products and/or services provided by other organisations – often referred to as SaaS (Software As A Service) – directly via the internet.
B2C – better known as a Business-to-Consumer – refers to the process of businesses selling products and services directly to consumers, bypassing any third-party retailers, wholesalers, or other middle person. In eCommerce terms, B2C typically refers to online retailers who sell products and services to consumers directly through the internet.
For security protocols like Open ID Connect (otherwise known as OIDC) and SAML, an Identity Provider – a.k.a. an IdP – is typically a web-based server/service that performs the role of verifying user credentials and, optionally, establishing and maintaining the SSO session for a user.
You can discover more about OIDC, SAML, and the value of SSO, at: a0.to/do/oidc, a0.to/do/saml, and a0.to/do/sso respectively.
GDPR – also known as the General Data Protection Regulation – is a privacy and security law, and arguably one of the toughest in the world. Though it was drafted and passed by the European Union (EU), it imposes obligations onto organizations anywhere who target or collect data related to people in the EU. The regulation was put into effect on May 25, 2018, and will levy harsh fines against those who violate its privacy and security standards, with penalties that can reach into the tens of millions of euros.
You can find out more about GDPR at https://gdpr.eu/what-is-gdpr
OAuth 2.0 stands for Open Authorization (version 2.0), and is a standard designed to allow a website or application to access resources hosted by other web based systems on behalf of a user. It leverages the concept of an Authorization Server, and replaced OAuth 1.0 in 2012 to become the de facto industry standard for what is often referred to as delegated authorization.
You can discover more about OAuth 2.0, and the role of an Authorization Server, at: a0.to/do/oauth2
A part of delegated authorization, Consent gives a user the ability to authorize the scope of operation(s) an application can perform when it’s accessing their user resources whilst acting on their behalf.
You can discover more about Consent, at: a0.to/do/apiz
An API – otherwise known as an Application Program Interface – commonly refers to code that allows application systems to communicate in a consistent manner in order to share information. Where an API is used to provide access to (protected) resources associated with a user, it is often referred to as a Resource Server. The term API-First Design, refers to an approach to software architecture that centers around the API.
You can read more about the value of API-First design at: https://auth0.com/blog/the-business-value-of-api-first-design
Machine Authentication provides secure access in a context where there is no user. This could be something that occurs as a result of a user action, or it could be a situation where no user was ever present. Instead of an interactive login, a fixed set of credentials are typically utilized.
You can discover more about machine authentication, at: a0.to/do/authn
Native Applications (often referred to as Native Apps) are user interactive applications that run natively on either a Mobile or a Desktop device. Such applications might be developed using a platform native technology stack – such iOS, macOS, Dwift, Android, .NET, etc. – or a technology stack designed to be used cross-platform, such as React Native or Flutter.
Machine-Machine interaction typically refers to the case where there is no interface for user interaction, nor is any interaction performed on behalf of a user. Machine-Machine interaction typically occurs as part of some background – e.g. daemon – processing, as a result of some (user) operation, or as part of some communication at a device level.
Backend Services is the term typically used to refer to API’s – or other executables – with which there is no direct user interaction. In the case of APIs, one or more routes will typically be made available with which a Web Application or Native Application may interact on behalf of a user.
Web Applications, otherwise referred to as Web Apps, are user interactive applications that run in the Browser (or some embedded browser context). Web Applications typically fall into two categories: Regular Web Applications – which are the more traditional type that run with the aid of a web server, and Single Page Applications – a.k.a. SPAs – which run entirely in the browser.
Relationship Based Access Control – known more commonly as ReBAC – is a method of control that restricts access based on particular relationships. The ReBAC paradigm provides for relationship hierarchies and typically allow for finer-grained access control; some implementations also allow for complex definitions that include algebraic relationship operators such as union, intersection, and difference.
You can discover more about ReBAC at a0.to/do/fga, and more regarding the various access control aspects of authorization at: a0.to/do/authz.
Attribute Based Access Control – known more commonly as ABAC – is a method of control that restricts access based on particular attributes – such as the day of the week, the time of day, or the location from which an access request originates. ABAC can be used in conjunction with other methodologies, such as RBAC, to create rich access control strategies.
You can discover more about ABAC, access control, and other aspects of authorization, at: a0.to/do/authz.
A JSON Web Token – otherwise known as a JWT (pronounced “JOT”) – is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties, in the form of a JSON object.
You can discover more about JWTs, as well as see them in action, at: jwt.io.
User Authorization is the process of determining the permission(s), as well as the consent, for the purpose of access control in a user context. User Authorization typically leverages user authentication as a pre-cursor, via the interactive Login with which we’re all familiar.
You can discover more about user authorization, at: a0.to/do/authz
In terms of OAuth 2.0, an Authorization Server is typically a web-based server/service that performs the role of verifying (user) credentials as a pre-cursor to determining access permission(s). As part of this, the Authorization Server is optionally responsible for obtaining user consent too.
You can discover more about OAuth 2.0 and the world of Authorization, at: a0.to/do/oauth2 and a0.to/do/authz respectively.
Developed by the OpenID Foundation, OpenID Connect – a.k.a. OIDC – is an interoperable authentication protocol that is based on the OAuth 2.0 framework of specifications (namely, IETF RFC 6749 and 6750). It provides a simplified way to verify the identity of users based on the authentication performed by an Identity Provider, and allows user profile information to be obtained in an interoperable and REST-like manner.
You can discover more about OpenID Connect, and the role of an Identity Provider (otherwise known as an IdP), at: a0.to/do/oidc
Business-to-Employee – more commonly known as B2E – refers to strategies taken by a company that focus on employees, rather than on consumers. In information technology terms, B2E typically refers to systems or services providing applications used by employees for productivity and the like.
First-factor is a term that applies to the authentication process for a user, and typically refers to the (interactive) login workflow used for user credential verification.
You can discover more about the various authentication factors, and how they are typically employed, at: a0.to/do/authn
Actions is the Auth0 flagship for extensibility that replaces Auth0 Rules and Hooks, and compliments additional functionality provided by the likes of Action Scripts et al.
You can discover more about Actions, and the other extensibility options in Auth0, at: a0.to/do/extensibility
Adaptive MFA is a flexible, and extensible, MFA policy developed by Auth0, to help protect your applications from attack without increasing friction for your users.
You can discover more about Adaptive MFA at a0.to/do/mfa, and discover more about Auth0 at: a0.to/discover
Logout – otherwise known as Logoff or Signout – is a process that’s essentially the inverse of Login. Logout typically occurs when a user explicitly terminates their session after they have finished interacting with an application. Effectively de-authenticating themselves. Logout can also occur implicitly, where the application itself will terminate the session if no user interaction has occurred for a given period of time.
You can discover more about logout, login, the signup process, at: a0.to/do/login
User Authentication is the process of identifying a user to your application, in order to secure access to the features it provides. It’s typically provided via the interactive Login with which we’re all familiar.
You can discover more about user authentication, at: a0.to/do/authn
SAML is an acroynym that stands for Security Assertion Markup Language, and is an open standard that was developed primarily for authentication within an enterprise environment. SAML is based upon the Extensible Markup Language (XML) format, and delivers functionality that enables a user to access multiple web applications using one set of login credentials – more commonly known as SSO.
You can discover more about SAML at: a0.to/do/saml
An SDK – otherwise known as a Software Development Kit, or Dev Kit – typically provides a set of tools and instructions to help developers build their applications. A good SDK will tend to focus on one specific topic, follow best practice guidance, and save a developer from having to do every tedious bit of coding themselves. Multiple SDKs will often be used when developing a project, helping to standardize development so that applications can work more easily and securely on different hardware, operating systems, and in cooperation with each other apps.
You can read more about the value of using SDKs at: https://auth0.com/blog/what-is-an-sdk
The term “Bad Actor” (a.k.a. “Threat Actor” or “Malicious Actor”) is often associated with a person, group, country, etc. that purposely, and usually repeatedly, engages in bad behaviour – such as causing trouble, committing crimes or doing harm to digital systems and the like.
You can discover more about how systems can be attacked, and the role of a Bad Actor, at: a0.to/do/protect
Vishing is a type of social engineering attack that typically happens over the phone, where malicious callers try to extract your personally identifying details to use in perpetrating some other malicious activity. The goal is often to gain access to your account, financial details, or other information of personally or financially sensitive nature.
You can discover more about this, and other types of attack, at: a0.to/do/protect
Phishing is the term typically used to describe the situation when attackers attempt to trick users into doing “the wrong thing” – such as clicking a bad link that will download malware, or direct them to a dodgy website that may attempt to steal their credentials.
You can discover more about this, and other types of attack, at: a0.to/do/protect