as @user454322 says, look up the OAuth2 spec ... it's widely-used and well-supported standard that will work well.
There are (bascially) 2 ways to deploy an authorization server:
1) As a reverse proxy (as shown in @user454322 's diagam). This is when all requests from the outside go through the OAuth2 server and then to your services. This centralizes the authorization concern, so that it's handled before any request reaches the services. This is the same as terminating SSL in the load balancer. In essence, the authorization server becomes a part of your network middleware, like the firewalls and load balancers.
- the primary downside is that implementing a reverse proxy can be tricky, especially if you have large payloads, or are doing clever things with HTTP (HTTP starts simple, but there are lots of complicated wrinkles it adds)
- you can buy "API management" solutions which provide the reverse proxy functionality, but add things like OAuth, metrics, throttling, etc.
2) As an authorization server. This is a slightly different layout, where each service takes requests directly (from the load balancers, etc.) Each request comes with an access token in the header. The service then makes an HTTP call to the authorization service to validate the token. The authorization server is responsible for authenticating users and granting tokens in the first place, your micro-services don't have to do that part.
- the primary downside is that each incoming request has to make a round trip to the auth service. That adds to your latency.
- a secondary downside is that you have to make sure the every one of your services calls the auth service -- otherwise, any services you don't will be open to the internet and unprotected.