MicroServices Authentication / Authorisation - authentication

Question

We are looking to implement a Micro Services architecture in the future. We don't want permissions at the API gateway to be very clunky and restricted to GET, PUT, POST etc.
We want granular application permissions to be stored and managed centrally, so apps only have to fetch them and not manage them.
I have included a picture of the draft architecture I have in my head as well as logic flow below.
My Question
Can this design pattern be implemented using any of the existing authentication/authorisation specifications such as OAuth2? If not, is it acceptable to create your own Authentication / Authorisation pattern for use with in a private network?
App Life cycle
A developer creates WebApp1
WebApp1 is registered in the Web App Registry Server by the developer. He/She also registers the custom permissions that the App exposes.
Users can have access granted or revoked to the granular permissions exposed by the App by an IT Administrator.
In the example above WebApp1 exposes two permissions CreatePost & DeletePost user1 only has permission to CreatePost
User Process Flow
An unauthenticated user accesses WebApp1 and is redirect to the Login screen.
The user's credentials are validated against LDAP and a UUID Authorisation token is generated. The token is stored in a Security Token Server and the user redirected back to WebApp1 with the token included in an Authorization Header.
WebApp1 requests the permissions this user has from the Web App Registry server, this can be done every x minutes and stores them in local state. The Web App Registry Server also checks the Authorization token is still valid.
WebApp1 checks every x minutes that the users token is still valid, if not the user is requested to login again (or a refresh token could be included with the original token that was sent to the app when the user Authenticated).

Answer 1

Interesting question - some thoughts below on achieving your goals via OAuth based design patterns:
AUTHORIZATION GOAL
The desired end state is usually to give yourself choices:
Use a pattern that enables any API component to do authorization
Sometimes you need to be close to the data source to enforce permissions.
Other times you may want some types of rule to be enforced via a dedicated service
MAPPING TOKENS TO PERMISSIONS
I like this way of doing things. In effect it is a Claims Based Architecture, and the information you need for authorization won't come solely from tokens.
My API Authorization Post describes an extensible pattern that starts with defining a claims / principal object in each API. Here is some sample code, where the Authorizer class provides an overview of behaviour on each API request.
WEB APP REGISTRY
I would be careful about creating components that could come under heavy load and become a bottleneck for your whole software platform - should you need one of these?
CLAIMS AND MICROSERVICES
A pattern that can work well is to design 2 levels of API. Interestingly, both of these can use claims and you can put authorization responsibilities anywhere you want - and give yourself choices:
Entry point APIs: exposed to the internet, do OAuth validation and naturally lock down what clients can do with access tokens:
Microservices: run in a locked down network and can freely call each other without OAuth plumbing
My API Platform Architecture
post explores this option, where claims are passed between microservices via headers.
ACCESS TOKEN VALIDITY
You can often simplify code by following the below rules, since there can be multiple reasons for tokens becoming invalid:
Keep access tokens short lived ~60 minutes
Handle 401 errors in the client as in this code