tl; dr

在应用程序外部-始终外部化授权。将授权逻辑与业务逻辑脱钩。

更长的答案

自从SOA开始以来（面向服务架构，API架构以及现在的微服务，这种趋势一直在打破应用程序孤岛，并以可以重用常见功能的方式设计系统。例如，您使用中间身份验证服务（我希望不会实现自己的身份验证方案）和中间日志记录机制。

授权同样如此。有一种叫做

ABAC实现：XACML& ALFA

通用方法

当今有两种实现ABAC的标准。 XACML提供语言和体系结构（请参见上文）。 ALFA提供了语言。

Ruby中的ABAC

检查此项目： CanCanCan 。

I have a brand new Rails api based application, where i need to implement authorization.

Overall Architecture:

React frontend -> Rails API layer -> Rails model/server layer

While exploring different approaches, I have got a confusion.

1. Should we put the authorization logic in API layer or Service layer?
2. API Layer Approach: We will build some authorization middleware that will sit between our front end and API layer and all our api calls will be routed thorough the authorization middleware to check if the user is allowed to call that parituclar api.
3. Service Layer: All the authorization check will go to service layer and we will have check before every db operation if the user is allowed to do so. (Using cancancan / pundit) and if the user is not allowed throw the error message to API layer.

It would be a great help, if someone could suggest based on their experience.

tl;dr

Outside the app - always externalize authorization. Decouple your authorization logic from your business logic.

Longer answer

Since the beginning of SOA (service-oriented architecture), API architectures and now microservices, the trend has been towards breaking down application silos and designing systems in such a way you can reuse common functionality. For instance, you use a central authentication service (you wouldn't, I hope, implement your own authentication scheme) and a central logging mechanism.

The same applies to authorization. There is something called externalized authorization which promotes:

• decoupling authorization logic from the application. Many dev frameworks already do that (Spring Security, Microsoft Claims, Ruby CanCanCan...)
• centralizing authorization logic into a single point of management.
• expressing authorization logic as human-readable policies. This means you can write policies such as
  • Doctors can view the medical records of patients they have a relationship with
• using attributes to define these policies: this is called attribute-based access control (ABAC). It is the de factor authorization model for new app developments (such as API). NIST published an excellent report on the topic in 2013.

Architecture

ABAC promotes the following architecture and flow (more details here)

• Policy Enforcement Point
• Policy Decision Point
• Policy Information Point
• Policy Administration Point

ABAC Implementation: XACML & ALFA

Generic approaches

There are 2 standards that implement ABAC today. XACML provides both a language and an architecture (see above). ALFA provides a language.

ABAC in Ruby

Check out this project: CanCanCan.