Every android developers are very well aware of Third party integrations like Twitter login, Facebook Login, Google Login etc. All of these Login Services are called as Single-Sign-On (SSO) kind of Authentication services i.e., Any apps which need to have direct login without giving much pain to app users they can just simply make use of these authentication services.
Well! I will not dive deeply into these concepts since my objective of this blog to throw some light on Okta Integration with android apps. Let’s not waste much time and get prepared to start.
Before I get started anymore with the phrase “Okta Okta” I request you to study the blog. https://support.okta.com/help/s/article/What-is-Okta
The specialty of okta Authentication is you can have one common sign for multiple apps. Let us go further in understanding the types of authentication
- SAML Authentication
- OPEN ID connect Authentication
SAML Authentication [ Secure Assertion Markup Language]
Let’s try to understand what gave the birth for SAML in the below context:
Authentication defines the way a user is identified and validated through some sort of credentials as part of a login flow. Most applications will present a login page to an end user, allowing him to specify a username and a password. In some cases, additional information may be required in order to locate the user — like a company ID or a client code. This information allows the Application to narrow down the search of the username applicable to the provided info. This is often used to allow the same username to exist across multiple tenants belonging to the different customer.
Most applications will have a user store (DB or LDAP) containing, among other things, user profile information and credentials. During login, the credentials are validated against this backend user store. The advantage of this approach is that it is simple because everything is managed within the application, providing a single and consistent way to authenticate an end user. However, if a user needs to access multiple applications where each app requires a different set of credentials, it becomes a hassle for the end user. First, the user will need to remember different passwords — in addition to any other corporate password (eg. AD password) that may already exist. The user is now forced to maintain separate usernames and passwords, dealing with different password policies and expirations. Second, this also creates a headache for administrators and ISVs when application users continue to have access to applications that should have been revoked.
Federated Identity :
Federated Identity started with the need to support application access that spans beyond a company or organization boundary. Imagine a relationship between a juice company (JuiceCo) selling its product to a large supermarket chain (BigMart). As an employee of JuiceCo, you need to access an application provided by BigMart to manage the relationship and monitor supplies and sales.
In this case, BigMart (who is providing this application) will need to take care of user authentication. The simple way is to require a different user name and password from users working at JuiceCo. But think about all the users that this application will need to maintain — including all of the other suppliers and their users who need to access the application.
A more elegant way to solve this problem is to allow JuiceCo and every other supplier to share or “federate” the identities with BigMart. As an employee of JuiceCo, you already have a corporate identity and credentials. What Federated Identity provides is a secure way for the supermarket chain (Service Provider) to externalize authentication by integrating with its suppliers’ existing identity infrastructure (Identity Provider). This type of use case is what led to the birth of federated protocols such as Secure Assertion Markup Language (SAML)
Request readers to go with the below blog for the depth explanation
https://developer.okta.com/standards/SAML/
TIME FOR PRACTICALS — — OKTA SAML AUTHENTICATION
The SAML flow is initiated with the Service Provider (SP), in this case, Okta, who then redirects the user to the IdP for authentication. On successful authentication, a user is created inside Okta, and the user is redirected back to the URL you specified along with an ID token.
Step 01: Navigate to the below website for creating your developer account:
https://developer.okta.com/signup/
Step 02: Once you sign up you gonna get the developer page something like below:
Step 03: Click the specific client that you wanted to integrate(My case Android) so it gonna specific guide for you.
Step 04: Click on applications just follow the below image:
Hurray! Congratulations on your successful journey with your initial and primary steps of building the service.
We need to pause for a moment and need to understand like how can we integrate with okta service in android platform……How…….?
In android platform we gonna use a library for integrating these okta services using AppAuth for android. Also, We can use the same library for IOS as well.
Please go with the below link for the Client SDK documentation:
https://github.com/openid/AppAuth-Android
I would love to show a small demo with the app execution please do have a look.
https://youtu.be/t1TirRgNddc
I have created a sample demo on the same. Do Download and run it once here is the below link:
https://drive.google.com/file/d/1lfGRhFr8vK2yu1vuaG0T6MGqgeFQXJJK/view
That’s all folks! I hope you were able to learn something new on authentication services. I will be continuing the second part for the same with including some other concepts using OKTA.
Read the blog and do share it. Any comments, questions or suggestions are most welcome.
Thank you for reading this!
The post A simple and secure authentication using Okta Services in android development(Part 01) appeared first on Wolken Software.
