You're right. Or maybe saying "I agree with you" is more pragmatic. Recent case in point - I have an app that fetches and saves a lot of data from and to a server. It has pretty heavy security requirements so I split out user registration and login into a separate server app. The client calls it, gets a token and uses it to access data in another service.
A customer just asked to two-factor authN. I can make that change without affecting any of the business services. Getting it wrong means little more than a short-lived denial of service.
In traditional SOA authN would be wrapped up with authR in a service interface or façade, fronting the monolithic app. Not nearly as extensible or flexible.
A customer just asked to two-factor authN. I can make that change without affecting any of the business services. Getting it wrong means little more than a short-lived denial of service.
In traditional SOA authN would be wrapped up with authR in a service interface or façade, fronting the monolithic app. Not nearly as extensible or flexible.