【问题标题】:REST API considerations for expansion in the futureREST API 未来扩展的注意事项
【发布时间】:2014-12-01 03:00:12
【问题描述】:

首先,一个小小的免责声明:这是我第一次尝试构建 REST API,所以请多多包涵 :)

我正在用 Java 为 Angular 应用程序设计一个 REST API,但我遇到了一个我真的不知道如何处理的情况。 对于初学者来说,API 将只服务于一个 Angular 应用程序,它基本上使用户能够编辑他们的属性,以及创建链接到他们各自用户的各种资源。

我无法处理的概念是将来允许其他应用访问 API。您将如何设计它以允许这种扩展?

我的想法是,每个 API 调用都将在 HTTP 标头中携带一个特定于应用程序的令牌,该令牌唯一地标识该应用程序。这将要求开发人员事先注册并接收令牌,以便在他的调用中使用。这种方法的问题是我不知道它到底有多安全。你认为这是一个很好的起点,还是我错过了一些重要的事情?

【问题讨论】:

    标签: java api rest expansion


    【解决方案1】:

    你几乎猜对了。您的方法的问题在于,欺骗应用程序 ID 非常容易,尤其是当它没有过期时。它通常的工作方式是,每个访问您的服务的应用程序都会有一个Application KeyApplication Secret。您使用app key 来识别应用程序,并使用secret 对服务进行身份验证并获取访问令牌,或者在每个请求中包含一个签名,该签名将使用应用程序机密作为密钥进行加密。 所以这里是建议的工作流程:

    • 客户端应用程序使用app key 和app secret 对服务进行身份验证
    • 服务返回 access token - 用于识别工作会话的内容
    • 客户端应用程序将在对服务的每个请求中包含access token,从而建立客户端身份
    • Access token 应该过期了
    • 该服务只能通过 TLS 工作,因为应用程序机密在身份验证调用期间以明文形式发送。

    这受到OAuth2 做事方式的启发,减去客户端应用程序可能希望访问您服务上的用户的想法(就像您可以使用第三方应用程序访问 Facebook 上的用户数据一样)。如果您确实有用户的概念,您可能想要使用 OAuth2,这里有一个很好的教程:http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified 您可能还想看看其他人如何保护他们的 REST 服务。这是 AWS,例如: http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html 希望对您有所帮助。

    【讨论】:

    • 非常感谢,这为我解决了问题。在我开始设计/编写任何东西之前,我想对整个身份验证过程有一个清晰的认识。
    • 进行自己的身份验证设计涉及很多风险。有关此问题的讨论,请参阅 soabits.blogspot.dk/2014/02/…
    • 确实如此。我一直在研究 OAuth 2 作为保护 API 的一种手段。似乎被业界广泛接受,这是一个非常重要的方面。
    猜你喜欢
    • 2014-10-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-05-17
    • 2023-03-11
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多