What does it takes to move an regular web application authentication to IF APIs based authentication?

[mbhadoria]

• I think my web application is secured. This application is built using loginname/pwd based authentication model. Should I still think of switching to API based authentication?
• What are the things that a user coming from the background of loginname/pwd based authentication need to know in order to make a leap to integration factor APIs ?

[gnulib]

There are following considerations when evaluating iF Login based Web Security as a Service in comparison to traditional solutions:

• is your application architecture API driven (e.g., micro services)
• is your application native cloud app
• do you have frontend separate from backend service (e.g., mobile clients or packaged frontend apps)
• liability factor for any security compromise versus ongoing cost of security updates

So, if the application has very simple architecture, and not much liability concerns, then a traditional authentication scheme of loginname/password with local storage is sufficient. Choice is between cost of implementing a local solution, or leveraging iF Login's free project tier with zero cost.

However, for any complex application that has native cloud architecture and/or API driven architecture and/or distributed architecture with frontend access separate from backend services, in such cases authentication and authorization solutions are critical, expensive and need to be continuously on par with industry standards. For these applications, iF Login becomes a very attractive proposal where a solid enterprise grade solution is available with no upfront cost and day 1 availability.

[gnulib]

From end user's perspective, authentication experience with iF Login based application would be slightly different in following sense:

• end users will authenticate themselves with iF Login service (skipped if their client is pre-authenticated, e.g. for existing browser session) to establish ownership of end user identity
• end users will explicitly grant authorization to the application to access their identity (this is reversed in the sense that application is requesting authorization from end user to work with their identity)

Now, technical explanation for this difference in user experience is because:

• iF Login is #BYOI based, which means end users own their identity, not the application
• end user, who is the identity owner, gives permission to the iF Login based applications to work with their identity
• end users do not authentication with the application, instead the application requests authorization to get access to their identity
• Identity for end users is hosted on IDP service from Integratingfactor.com and not on the application
• end users authenticate with IDP service to access their identity, so that they can grant access to application to work with their identity

In general, we need to understand the difference between authentication and authorization. Application security relies on both, proper authorization for correctly authenticated identity. In the iF Login framework, applications assign roles to users and implement RBAC to protected resources based on user role. IDP service is responsible to correctly authenticate the user's identity and provide the associated roles of that identity to the application.