Firstly, sorry for the delay. I stopped receiving notifications when there were new messages in the forum.
The tempting option is always to create an authentication web service. You store all the user credentials in one place and perform an RPC HTTP request to validate the user's credentials. So each of your three contexts might do this.
Alternatively, your users could log into this api directly which provides them with a session token. This session token could be stored in a distributed cache which each of your three BCs can query to validate the users token on each request.
Again though, you've got RPC calls and a single point of failure for all three services.
Another way to look at this scenario is to actually consider your service boundaries. Are those really three bounded contexts or could they live within a single bounded context and share a database? Did you arbitrarily determine those boundaries, or do they exist in the problem domain? Do they have their own linguistic nuances, or do they represent distinct business capabilities?
If your services boundaries are correct, and you'd rather not have fragile RPC calls in your workflow, then there are asynchronous approaches. One approach suggested by Udi Dahan almost 10 years ago is to load the entire set of usernames/passwords into memory inside each BC http://udidahan.com/2007/11/10/async...for-web-farms/
You could modify Udi's approach so that each bounded context uses its own private distributed cache to store the credentials. That way if you've got 10 instances of your API, or you have a number of smaller services in a BC, they don't all have to pull in the data. Remember, it's generally ok to share a database or cache within a bounded context.
Hope this helps but please continue to ask away if you have further questions.