While this is a security question, I'd like to make you aware of another consideration:

##Performance considerations

Creating a micro web service to handle authentication might be a good idea in some cases, this depends on the use cases.

Yet, you might want to consider that establishing many https connections (for many requests) comes at a cost as well. It might be useful in terms of load minimization (as that seems to be a concern) to have the two services establish a long lived tunnel that is used by multiple connections.

##As to the security considerations

• The actual, user facing web service will act as a TLS client in this szenario.

It is extremly important that the trust store is working as intended (e.g. trusting only the certificate of the password service) and that the password services' private key as well as the web services' remains private.

Else, - the service could become vulnerable to MITM attacks (especially when running on different machines) - attackers could directly interact with the password service, maybe DOSing it with extremely big payloads or being able to use indirect side channel timing attacks.

• The web service and/or the password service should preferably use some strategy to be sure to mitigate possible timing attacks and DOS.

Also, of course, the increased scalability, seperation of concerns and especially network segmentation (which are good and important), comes at a price: Implementing the logic may become more complex and you might introduce subtle problems you are not aware of. This is especially true if you are not used to that.

An example of increased complexity could be: On email changes, who handles the actual commit atfer the new email as been verified and how, e.g. who is authorative for changing data that is duplicated across the databases? Do you want to start network IO within a database transaction?

##As to the hashing function

There is a question here about hashing passwords securely that has very good answers.

Consider that there is no need for you to use bleeding edge research hashing functions. The others (PBKDF2, bcrypt and scrypt) are as-good for this purpose and you do not have to expect a severe problem to be found anytime soon as they have had time to be thourougly peer reviewed.

While this is a security question, I'd like to make you aware of another consideration:

Performance considerations

Creating a micro web service to handle authentication might be a good idea in some cases, this depends on the use cases.

Yet, you might want to consider that establishing many https connections (for many requests) comes at a cost as well. It might be useful in terms of load minimization (as that seems to be a concern) to have the two services establish a long lived tunnel that is used by multiple connections.

As to the security considerations

• The actual, user facing web service will act as a TLS client in this szenario.

  It is extremly important that the trust store is working as intended (e.g. trusting only the certificate of the password service) and that the password services' private key as well as the web services' remains private.

  Else,

  • the service could become vulnerable to MITM attacks (especially when running on different machines)
  • attackers could directly interact with the password service, maybe DOSing it with extremely big payloads or being able to use indirect side channel timing attacks.

• The web service and/or the password service should preferably use some strategy to be sure to mitigate possible timing attacks and DOS.

Also, of course, the increased scalability, seperation of concerns and especially network segmentation (which are good and important), comes at a price: Implementing the logic may become more complex and you might introduce subtle problems you are not aware of. This is especially true if you are not used to that.

An example of increased complexity could be: On email changes, who handles the actual commit atfer the new email as been verified and how, e.g. who is authorative for changing data that is duplicated across the databases? Do you want to start network IO within a database transaction?

As to the hashing function

There is a question here about hashing passwords securely that has very good answers.

Consider that there is no need for you to use bleeding edge research hashing functions. The others (PBKDF2, bcrypt and scrypt) are as-good for this purpose and you do not have to expect a severe problem to be found anytime soon as they have had time to be thourougly peer reviewed.