|
Answer» Basic Authentication is natively supported by almost all servers and clients, even Spring security has very good SUPPORT for it and its configured out of the box. But it is not a good fit for Microservices due to many reasons, including - - We need credentials (username and password) every time we authenticate. This may be fine where all the participants can share the secrets SECURELY, but Users may not be willing to share their credentials with all the applications.
- There is no distinction between Users and Client Apps (an application that is making a request). In a realistic environment, we often need to know if a real user is making a request or a client app is making a request (for inter-service communication).
- It only covers authentication. what about scopes, Authorizations? Basic Auth does not support adding additional attributes in the authentication headers. There is no concept of Tokens in basic auth.
- Performance reasons for BCrypt Matching. Passwords are often stored in the database using one-way hash i.e. Bcrypt, it TAKES a lot of cpu cycles depending upon the strength (a.k.a. log rounds in BCrypt) to compare the user’s plain password with db saved bcrypt password, so it may not be efficient to match password on every request. The larger the strength parameter the more work will have to be done (exponentially) to hash the passwords. If you set the strength to 12, then in total 212 iterations will be done in Bcrypt Logic. Usually, 4-8 passwords can be matched per second on a T2.Micro instance on Amazon AWS instance. See BCryptPasswordEncoder for more info.
- If we use Basic Auth for a mobile application client, then we might have to store user’s credentials on the device to ALLOW REMEMBER me feature. This is quite risky as anyone getting access to the device may steal the plain credentials.
|