1. 15

OAuth would be a big step toward a proper API, e.g. for mobile apps.

Benefits of OAuth over cookies, which we have now:

  • Users can grant narrower permission scopes to applications that should not require full access
  • Applications can be blocked by the admins to reduce abuse
  • Auth tokens can be revoked by users on a per-app basis
  • More difficult to use stolen OAuth tokens compared to cookies

There was a GitHub issue proposing an OAuth provider, but it was closed without any discussion or reasoning in January 2016: https://github.com/lobsters/lobsters/issues/260

I thought we could revisit the proposal as a meta discussion, to figure out if there are any dealbreaking downsides to adding OAuth support. Or if no objections are found, then the issue could be made up-for-grabs for anyone who is interested in implementing support.


  2. 4

    What problem does this solve? What does it cost in increased complexity for the codebase?

    1. 3

      What problem does this solve?

      It improves the security surrounding third-party scripts and applications. Today it is already possible to write third-party scripts, with authentication using cookies. But cookies are easily abused, so OAuth improves on that security problem.

      @nickpsecurity mentions some reasons why an API in general is better than no-API. I’m talking about the OAuth aspect only.

      What does it cost in increased complexity for the codebase?

      A lot of it would be isolated from existing logic: OAuth would have a mostly-separate login flow. It would add new mostly-isolated endpoints for registering API consumer applications.

      It would add maintenance burden to JSON APIs: As a best practice, there would be new endpoints (/api/v1/...) corresponding to each of the existing (~3-5?) JSON read-only endpoints, as well as new endpoints for performing actions as a logged-in user (voting, posting, commenting). The business logic remains the same, but the new endpoints would route through the OAuth validator, instead of today’s existing cookie/session validator.

      Existing JSON endpoints could either be deprecated or kept around, depending on to what extent they’re being used today.

      1. 3

        Given this is first-and-foremost a site for techies, would a (somewhat simpler) ‘generate an API key and choose permissions via the profile screen’ be sufficient?

        The permissions I can think of:

        • Vote
        • Post
        • Comment
        • Suggest tag
        • Flag
        • Hide
        • Save
        • Invite
        • Read PMs
        • Write PMs
        1. 2

          Let me clarify: I think what you’re proposing is an API key tied to a single account, rather than an OAuth application that can potentially service multiple different accounts. Thereby eliminating the OAuth login flow.

          Have you seen such a system in use anywhere? One benefit of OAuth is that it’s a standard, so people sort of understand the ins-and-outs and use cases of it. An ad hoc API key system would probably work on a technical site like lobste.rs, but may be confusing to API consumers and/or site maintainers/forks, solely due to the fact that it’s ad hoc.

          Which brings me to another point: the lobste.rs codebase can be forked and used for non-tech sites. So simplifying the end-user experience, using OAuth, would be much preferable given that use case.

      2. 2

        Far as an API, people are always makimg requests about changes to the site to reflect their preferences. An API would let them code up solutions themselves or for sharimg with others. This happens regularly on HN with its API. This is also a site full of programmers who could handle that with UI preferences ranging from native apps in terminals to Electron apps built on web browsers.

        Might also help on productivity where people could scrape the site to consume it later in their own way. They just get digests or something based on certain tags or users. There’s more possibilities.

      3. 1

        OAuth is always nice to find, and use, in the sites and services we love. However I feel this thread needs a little clarification, as ‘Implement OAuth 2.0 in Lobste.rs’ is a bit vague.

        1. Lobste.rs as an OAuth Provider - This means that other websites or apps can use your lobste.rs account to verify your identity within their app. I don’t believe this is what this thread is trying to suggest.

        2. SSO (Sign Sign-on) - Use other OAuth providers such as GitHub, Twitter, Google, etc. to validate & authenticate someones identity on the authentication layer to lobste.rs. I see this being able to slot into the LoginController quite easily. There are a bunch of example apps out there which allow username/password authentication in line with SSO.

        I personally feel like this is a good idea, which with lots of user input on the authentication flow could work nicely.

        1. 13

          Neither 1 or 2 if I read the OP correctly.

          OAuth is for authorization, not authentication. If you want authentication you’d use something like OpenID Connect (based on OAuth 2.0). The OP suggests implementing an API on lobste.rs protected by Bearer tokens instead of cookies.