Client authentication is always the most important and shared aspect of the app's architecture. This is particularly crucial in the cloud, where there are many users in a spread-out system.
Already excited to explore OKTA? This one-stop platform can bring enormous opportunities to your career. Without further ado, let’s understand the architecture of OKTA.
To learn more about your customers and give them the most effective digital experience, you require a unified client identification system.
What is Okta?
Okta offers a lot of different Identity as a Service (IDaaS) options for both employees and customers. I'll mostly talk about authentication, self-service registration (SSR), and authorisation for the customer ID and access management (CIAM) solution.
Okta not only gives customers a cloud-based application to manage their SSO instances and start apps, but it also gives them a number of ways to connect to other systems (you must enable SSR for options #1 and #2 below).
Hosting Sign-In Page for Okta
This implies you are going to utilise the "out of the box" (OOTB) sign-in page that Okta gives you for the application. Okta will be hosting and taking care of the sign-up and sign-in process. You can change the experience by changing the domain name, HTML for the sign-in page, icons, and links. You can just use Okta to make your app and put this behind Okta's login page. It is the less flexible choice out of the three, but it is a fully controlled cloud-based choice, which means it gets to market faster and has fewer codes to manage. To be an expert in network security systems, Okta training is very helpful.
A sign-in box
You can also add the Okta Sign-In Widget to your app; that's the second choice. If you want to get the Okta sign-in tool, you can do so through sites such as the Okta CDN or NPM. Depending on your requirements, you can change how the widget works or make your event managers. You continue to adhere to the identical Okta default flows and processes when you choose this choice.
However, you have more control over where and when the sign-in widget shows up in the application, and you don't have to write every single code that links to Okta.
GUI with Okta SDK and API
The last choice is to use the Okta SDK as well as API to make your own sign-in and sign-up screens for your apps. If you choose this option, you have the greatest amount of liberty to choose the use case (like letting people sign up and login without a password), the user experience (like forward-thinking profiling, fields, messages as well and internationalization), the business logic (like sending a custom mail from the email server when a user is locked out), as well as the tech stack. However, you must create all of these things yourself.
Solution Architecture
You can use the solution layout you can construct here as a model to think about how to handle your situation. We are making a new web-based application for my organization that deals with businesses, and it needs a way for users to sign in and log in.
In my app, there is also an admin area that customer admins have access to. Adobe Experience Manager (AEM), Amazon Web Services (AWS), as well as Okta are the three major parts of this architecture.
AEM
If you'd like to gain full control throughout the overall appearance, user flow, as well as company logic of the background, you should build the web app like a SPA. This entails customized sign-up and sign-in, as well as the admin experience. You can use AEM as a headless Content Management System for the SPA and have the same content management team handle all the writing, publishing, and languages in one place.
AWS
The SPA will be stored in Amazon S3 and served across the perimeter by Amazon CloudFront. It will be possible to use the SPA's REST APIs in a number of serverless Lambda Functions, such as this one. They have an Amazon API Gateway in front of them that handles all API accesses, bandwidth limits, authentication, permissions, and other things.
For a smoother and faster sign-up process, you could give users the bare minimum of information they need to sign up at first. So, once the user has registered and an Okta account has been created, you will get a message or signal to an AWS SNS (Simple Notification Service). This message or signal will then be sent to all the business services that adhere to the account creation topic, such as an email service to send the user a welcome message as well as an account validation service to make sure the registration was successful.
To improve speed and fault tolerance, you can put an AWS SQS (Simple Queue Service) in front of each of those services. So, let's say I want to call an API for a third-party name compliance check provider first.
If it originates back as a pass, I will change the user record in Okta as well as the Marketo lead to reflect that. If it gets back to collapse, I must go through the account by hand to make sure it is compliant. Here is a flowchart for the same thing.
Account validation workflow
Okta
Okta will be the one who knows the real name of each user (Universal Directory), remain the identity provider (IDP), and manage the user's lifecycle management, rules (like sign-on, a username and password MFA, and IDP discovery), and do API Access Management.
The application's permission will follow the OIDC norm, so it will either let people in or not. The Authorization Code flows in the PKCE as the source code flows to trade ID and access tokens for SPA as it is a browser-based app. In Okta, you can make a custom authentication server for my game. The customer users will put into a group, "admins for the customer."
This way, the rules for access may link to the group rather than a single person, which is the best way to do things. After that, make a new administrator scope in the permission server. After that, create a policy on access and rule so that only those in the admin groups for the customers can get to the administrator scope. I can also add my own custom properties to the Okta user account schema to show the type of admin role the user has.
For example, an org administrator role can oversee the whole organization, a group admin role is able to oversee certain groups in the organisation, and so on. Then you may utilise Okta expression language to claim the administrator's scope as well as add this user property to the access token jwt.
You can now control who can see and use my admin screen as well as customer administrative REST APIs according to their job (RBAC).
Okta Base IAM Architecture Diagram
What's new in Okta architecture?
There are a number of fresh features coming soon to Okta that will be important for CIAM. Workflows: Okta Workflows offers a workflow engine for automating identity-centric operations. As of right now, workforce identification is GA. It ought to expedite a few of the typical CIAM management of the lifecycle applications when it arrives for customer identity.
In order to achieve customized experiences such as passwordless authentication as well as growing profiling, Okta Identity Engine divides the fundamental identity lifecycle (which includes registration, authentication, as well as authorization) into four steps: Individuality, Authorize, Enroll, as well as Issue.
Conclusion
Developing CIAM requires careful consideration of performance, scalability, resilience, security, as well as user experience; this is not always a straightforward undertaking, particularly for large businesses.
0 Comments: