1

I'm building a plugin for an RSS desktop client which allows users to directly flattr things (i.e. blog posts) from within the client. Since it's a Java application I use flattr4j, which itself works fine so far.

My only remaining problem centers around the authorization workflow, which uses OAuth 2.0. Since flattr uses the authorization workflow described in section 4.1 of the OAuth 2.0 spec, I need to adhere to the prerequisites mentioned there, i.e.

The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. As a redirection-based flow, the client must be capable of interacting with the resource owner's user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server.

I managed to implement this workflow by

  1. embedding a web browser control into my application (I could problably use the user's real web browser as well)

  2. running a tiny local HTTP server which gets hit by the web browser via the OAuth callback URL mechanism in order to receive the OAuth code

Especially the last point looks error-prone to me. Since I need to register the callback URLs in advance (e.g. in my case http://localhost:port/whatever), I'm forced the speculate about a safe, non-used local port in order run a local HTTP server which receives the OAuth code at the end of the authorization workflow.

On the other side the flattr4j documentation mentions a different workflow, which looks more appealing to me for my use case:

"Client" based applications cannot offer a callback URL. Desktop or mobile device applications, for example, do not run a web server at all. For client based applications, Flattr will show a validation code on the website. The user will be required to enter the code in your application, in order to complete the authentication process.

And some lines further down:

When the user accepts, a validation code is generated by Flattr. If the application was registered as "Browser" typed, the callback URL you stated will be invoked with the code and the state as parameters. For "Client" applications, the code is presented to the user instead, and he is asked to enter the code in your application manually.

This workflow might not be perfect, but much more robust for a desktop application in my opinion.

(As for the application registration: I registered my application with the platform Desktop (Any). The platform seems to be more fine-grained compared to the above mentioned "Browser" vs. "Client" alternatives.)

So my questions are:

  1. Is a callback-less OAuth workflow still supported by Flattr? (Was it ever supported?)
  2. If so: how can I initiate this workflow?
  3. If not: are my concerns valid, or is the "open web browser, initiate authorization process and receive OAuth code via locally running HTTP server" just the way to go? Are there any alternatives that I overlooked?

UPDATE There is another option which I'm investigating now: I set up an "OAuth landing page" which is used as the callback URL. This website's only purpose is to display the OAuth code, which then can be copied to the Desktop application by the user. Not perfect, but looks more robust to me at the moment...

4

1 回答 1

1

flattr4j 文档还说当前的 Flattr API 不支持“客户端”授权。API 的早期版本（直到 2012 年 4 月）支持无回调 OAuth，但现在不再支持，而且似乎不会再次出现......

还有一种替代方法，用于 Android 系统。您可以在您的操作系统中注册一个自己的协议（例如“flattr4j://”）并将一个适当的回调 URL 传递给 Flattr。当身份验证过程返回此回调 URL 时，您的操作系统将调用您的应用程序并传入应用程序密钥和秘密。但是，我认为这种方法很难实现，尤其是当您尝试找到独立于操作系统的解决方案时。

可悲的是，没有其他方法我会知道。

于 2013-09-09T14:54:33.487 回答