1:51pm

Aaron Parecki

#oauth2

  • I've seen this done a few ways: • The Device Flow: https://tools.ietf.org/html/draft-ietf-oauth-device-flow which is what you see on browserless devices like the Apple TV logging in to a cable provider from your phone. A short code is generated and displayed on the screen, you launch a browser on your phone and enter the code. This would work just as well from the command line on the same device. • I've also seen apps use the authorization flow, by displaying the authorization URL on the command line prompt and instructing the user to open it in a browser. The redirect URI is a hosted web page that displays the authorization code and instructs the user to paste it back at the terminal. • The command line app can launch an HTTP server on localhost and use that as the redirect URL for the authorization code flow. This option ends up being the most seamless since it works like a traditional flow without any special instructions to the user.
    Portland, Oregon, USA
    #oauth #oauth2
  • Patrick Schaller http://F3Development.com   •   May 4
    Sorry, I meant I'm being told the URL can't be visible and they are holding up other mobile apps login as examples that do not show it.
    @rogue__leader Yeah sorry, 140 chars isn't enough 😭 Before SFSafariView, the only way to securely do OAuth was to launch the native Safari browser. This meant you'd get bounced out of the app, which a lot of developers didn't want to do to their users. I don't disagree that this was a bad experience, and plenty of people feel the same. What ended up happening is people instead started embedding the WebView into their apps, in order to avoid having their users bounce out of the app and come back. The compromise in this case is that people would have to type their password to log in, because the embedded WebView doesn't share cookies with the system browser. It took Apple a long time to roll out SFSafariView, so there are just a lot of apps out there that still have the embedded WebView. Advantages of WebView: • Does not make the user leave the app to complete the OAuth flow Problems with WebView: • User has no way to verify they are on the real website, so phishing attacks are undetectable • Does not share system cookies, so users have to type their password every time Advantages of SFSafariView: • Does not make the user leave the app to complete the OAuth flow • The user can see the address bar so can verify they're on the correct website • Shares system cookies, so the user won't have to type their password if they've already signed in using the native Safari app I should probably turn this into a proper blog post.
    Portland, Oregon
    2 replies
    #oauth2
  • Patrick Schaller http://F3Development.com   •   May 4
    @aaronpk I was just reading your article https://goo.gl/IF9r2O which was helpful. Is using SafariViewController the only safe auth on iOS?
    @rogue__leader Thanks! That, or launching Safari or the service's native application. SafariViewController will provide the best UX.
    Portland, Oregon
    4 replies
    #oauth2
  • Bryan Stearns ‽ http://selfamusementpark.com/   •   Apr 6
    Got frustated trying to find OAuth2 docs that made sense to me; found @aaronpk's https://www.oauth.com/ and now it's clear! Thanks, Aaron!
    @bryanstearns Awesome! Glad it's been helpful!
    Portland, Oregon, USA
    #oauth2

  • Day 86: Updating IndieAuth Docs #100DaysOfIndieWeb

    Thu, Mar 16, 2017 5:22pm -07:00

    Beginning a slow project of updating the docs about the IndieAuth spec, today I started by updating a few pages on the wiki. Right now, most of the docs about IndieAuth (the spec), and how to use it, live across a variety of pages on the wiki, grouped together at https://indieweb.org/Category:IndieAuth.

    My goal with the spec IndieAuth is to make it an extension of the OAuth 2.0 spec. It has always been based off of the OAuth 2.0 spec, but I've never written it up properly as an extension. It's always been just a series of how-to guides. Additionally, I had originally started by specifying all of the responses being form-encoded responses, whereas the OAuth 2.0 spec says all responses must be JSON format. I've been slowly converting my various apps that use IndieAuth to support both, based on the HTTP Accept header, although I haven't publicized this much yet.

    Today's project was updating the existing IndieAuth documentation on the wiki to explicitly include the JSON versions as a valid response format.

    Eventually I hope to write up IndieAuth as a formal extension to OAuth 2.0, in the same format that something like the Device Flow is an extension.

    Portland, Oregon
    1 like 1 reply 1 mention
    #100daysofindieweb #micropub #indieauth #oauth2
  • Uber Developers (developer.uber.com)
    "OAuth 2.0 is a specification outlined in RFC 6749 that allows third-party services to make requests on behalf of a user without accessing passwords and other sensitive information. If you are unfamiliar with OAuth 2.0, check out Aaron Parecki's "OAuth 2 Simplified"."
    Portland, Oregon
    #inthewild #press #oauth2
  • @jaredhanson oh funny! I got token_endpoint from OpenID Connect: http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata I will take a look at the OAuth 2 link rels tho.
    Portland, Oregon, USA
    #oauth2 #webmention #oauth
  • Happy to announce https://oauth.com - a guide to building OAuth 2.0 servers! #oktane16
    Las Vegas, Nevada, USA
    33 likes 22 reposts 2 replies 3 mentions
    #oktane16 #oauth #oauth2
  • Just launched a big reorganization of https://oauth.net which should make it easier to find things! 🔒 #oauth2 #oktane16
    Las Vegas, Nevada, USA
    7 likes 2 reposts
    #oauth2 #oktane16 #oauth
  • @beaugunderson Your best best is to not use the client secret, and redirect to the app's registered protocol handler. Or dynamically generate a client secret when the app first launches (unique to each app). Sounds like this would be a good blog post.
    Portland, Oregon, USA
    1 like
    #oauth2
  • Implementing OAuth 2.0 access tokens | NimbusDS Blog (nimbusds.com)
    #oauth2 #oauth
  • Well this is progress... an in-app browser that shows the address bar and shares system cookies
    Portland, Oregon, USA
    3 likes 1 repost
    #ios9 #oauth #oauth2 #ios
  • Changes in iOS 9.0 (developer.apple.com)
    SFSafariViewController can be used to display web content within your app. It shares cookies and other website data with Safari, and has many of Safari's great features, such as Safari AutoFill and Safari Reader. Unlike Safari itself, the SFSafariViewController UI is tailored for displaying a single page, featuring a Done button that takes users back to where they were in your app.
    #oauth #oauth2 #ios #ios9
  • Into the symmetry: Open redirect in rfc6749 aka 'The OAuth 2.0 Authorization Framework' (intothesymmetry.blogspot.ch)
    #oauth2 #security
  • Janrain: User management platform for the social web (rpxnow.com)

    OAuth provider guide

    #oauth #oauth2

  • So you implemented an OAuth 2.0 API...

    Thu, Jan 15, 2015 12:15pm -08:00

    While OAuth 2.0 is a good framework for building an API, the spec itself leaves many things un-specified, and it's up to the implementer to make a decision based on their own security requirements. As such, most OAuth 2.0 implementations are not interoperable, which is often cited as a failure of OAuth 2.0. On the other hand, the current state of OAuth 2.0 implementations is that they are often similar enough that developers don't need to learn too many new concepts when dealing with them.

    This post documents all the ways in which OAuth 2.0 implementations may differ. All implementations of OAuth 2.0 have made decisions about these things (whether intentional or not), otherwise they are incomplete implementations.

    Every place in the spec that mentions things are a "MUST" are assumed to be implemented correctly. In other words, this does not ask you to verify that you implemented required parts of the framework correctly.

    Client Registration (Section 2)

    How do developers register a new client application?

    • on a web page (link to registration page)
    • programmatically (link to docs)
    • other (please describe)

    Aside from the client type and redirect URIs, what information is required or requested when registering an application?

    • application name
    • web page
    • description
    • logo image
    • acceptance of legal terms
    • other info:

    Client ID (Section 2.2)

    Clients should avoid making assumptions about the length of the client ID.

    What is the maximum string length of client IDs issued?

    Client Authentication (Section 2.3)

    What form of client authentication is supported?

    • Client ID and secret (this is the most common)
    • Public/private key pair
    • Other

    Client Password (Section 2.3.1)

    If clients are issued a client_secret, which authentication mechanisms are supported for client identification:

    • HTTP Authorization header (HTTP Basic Auth)
    • POST body parameters, client_id and client_secret (not recommended)

    Other Client Authentication Methods (Section 2.3.2)

    If clients are not issued a client_secret, describe any other HTTP authentication schemes used to authenticate clients:

    Protocol Endpoints (Section 3)

    Please specify the authorization endpoint and token endpoints. (note: this is only required here if your endpoints are specified in your documentation)

    • Authorization endpoint:
    • Token endpoint:

    How do clients obtain the location of the authorization and token endpoints? The most common way is to specify them in the API documentation, although an automatic discovery method may be used instead.

    • API Documentation
    • Other method:

    Authorization Endpoint (Section 3.1)

    How does the authorization endpoint authenticate users? (e.g. requires username and password logins each visit? maintains session cookies?)

    Response Types (Section 3.1.1)

    Aside from "code" and "token", are any additional response types supported?

    • Yes, additional types:
    • No

    Redirect Endpoint Confidentiality (Section 3.1.2.1)

    • Are redirect endpoints required to be HTTPS? Yes No
    • If HTTPS is not required, does the authorization endpoint warn users about the insecure redirect endpoint? Yes No

    Redirect URI Registration (Section 3.1.2.2)

    Registration of the redirect endpoints is required for public clients and clients using the "implicit" grant type. Aside from these uses, are all clients required to register redirect URIs?

    • Are all clients required to register their redirect URIs? Yes No
    • Is the registered redirect URI required to match exactly? Yes No
    • If both previous answers are "no", does the authorization server support a variable query string component of the registered redirect URI? Yes No
    • Can clients register multiple redirect URIs? Yes No

    Note: if registration of redirect URIs is not required for all clients, then your authorization endpoint can be used by an attacker as an open redirector.

    Invalid Redirect Endpoint (Section 3.1.2.4)

    • Does the authorization endpoint inform the user that a given redirect endpoint is invalid?
      Yes No

    If the answer is "no", please describe what happens when an invalid redirect URI is provided in an authorization request. (The authorization endpoint must not redirect to this endpoint.)

    Access Token Scope (Section 3.3)

    • Is it possible for the authorization server to ignore (or add) scopes to the values requested during authorization? (For example, giving users the ability to not grant certain scopes requested by the application.) Yes No
    • Does the authorization server document the default scope if none is specified during authorization? Yes (Documentation URL: ) No

    Authorization Response (Section 4.1.2)

    • What is the lifetime of authorization codes? (Maximum of 10 minutes is recommended)
    • If an authorization code is used more than once, does the authorization server revoke all access tokens granted using the authorization code? Yes No
    • What is the maximum size of authorization codes issued?

    List any other parameters returned, as well as their maximum sizes:

    Authorization Error Response (Section 4.1.2.1)

    • If the request fails due to an invalid redirect URI or missing client ID, does the authorization server inform the user of the error? Yes No
    • Does the error response contain an error_description field with a human-readable description of the error that occurred? Yes No
    • Does the error response contain an error_uri field which links to a human-readable web page about the error? Yes No

    Implicit Grant (Section 4.2)

    Implicit Grant Access Token Response (Section 4.2.2)

    When does the access token response include an expires_in parameter?

    • Always
    • Sometimes
    • Never

    If the expires_in parameter is not returned, the default value of the expiration is:

    • Does the response always include the scope of the access token? (Optional if it's identical to the scope requested by the client.) Yes No

    • What is the maximum size of authorization codes issued?

    List any other parameters returned, as well as their maximum sizes:

    Authorization Error Response (Section 4.2.2.1)

    • If the request fails due to an invalid redirect URI or missing client ID, does the authorization server inform the user of the error? Yes No
    • Does the error response contain an error_description field with a human-readable description of the error that occurred? Yes No
    • Does the error response contain an error_uri field which links to a human-readable web page about the error? Yes No

    Password Credentials Grant Type (Section 4.3)

    Describe what types of clients can use the password credentials grant type:

    Authorization Request (Section 4.3.1)

    Describe how the user enters their credentials, e.g. a username and password prompt, client certificate auth, or whether the server uses or requires two-factor auth:

    Access Token Request (Section 4.3.2)

    Since the access token request involves sending the user's password to the authorization server, the server must protect against brute-force attacks. Describe what type of protection is used, e.g. rate limiting, sending alerts to the user, etc:

    Access Token Response (Section 4.3.3)

    • Does the client receives a refresh token when using the password credentials grant type? Yes No

    Client Credentials Grant (Section 4.4)

    What type of client authentication is used for the client credentials grant? e.g. client ID and secret, public key auth, etc.

    • Client Credentials (client ID and secret)
    • Others:

    Can clients use the client credentials grant to request access to resources of other users who have been previously authorized? Yes No

    If yes, describe how clients indicate which user they requesting an access token for. E.g. specifying a username, user ID, opaque token, etc.

    Access Token Response (Section 4.4.3)

    • Does the client receive a refresh token when using the client credentials grant type? (Not recommended) Yes No

    Extension Grants (Section 4.5)

    Authorization servers may support additional extension grant types such as SAML. List any additional grant types that are supported, along with links to their documentation.

    Successful Access Token Response (Section 5.1)

    • Does the access token response include an expires_in parameter indicating the lifetime in seconds of the access token? Yes No
    • If not, what is the default value: , or describe another way the expiration time is indicated:
    • Refresh tokens are returned for the following grant types:
      • Authorization Code
      • Implicit
      • Client Credentials
      • Refresh Token
      • None of the above
      • Describe any other conditions under which a refresh token is or is not returned when requesting an access token. E.g. only for specific clients, etc:
    • What is the maximum size of access tokens issued?
    • What is the maximum size of refresh tokens issued?
    • List any other parameters returned, as well as their maximum sizes:

    Error Response (Section 5.2)

    • Does the error response contain an error_description field with a human-readable description of the error that occurred? Yes No
    • Does the error response contain an error_uri field which links to a human-readable web page about the error? Yes No

    Refreshing an Access Token (Section 6)

    • Does the authorization server issue new refresh tokens when a refresh token is used? Yes No
    • If a new refresh token is issued, is the existing refresh token revoked? Yes No

    Accessing Protected Resources (Section 7)

    Describe how the resource server validates access tokens: (e.g. uses the authorization server's private API, shares cryptography keys, shares a database connection)

    Describe how clients send the access token to the resource server. This typically involves sending the access token in the "Authorization" request header.

    Access Token Type (Section 7.1)

    Which access token types are accepted?

    • Bearer tokens
    • MAC tokens
    • Others:

    Error Response (Section 7.2)

    Does the resource server inform the client of an error? Yes No

    New Authentication Schemes

    If you are using a new authentication scheme (other than Bearer tokens), there are several things to take into account when handling error responses. Please describe the following:

    • How your new authentication scheme provides error status codes to the client
    • What is the name of the error parameter? (e.g. error)
    • Does your scheme also return an error_description parameter? Yes No
    • Does your scheme also return an error_uri parameter? Yes No

    Security Considerations (Section 10)

    Client Authentication (Section 10.1)

    • Are client passwords (or other credentials) issued to clients for specific devices? (e.g. an individual installation of an application on a device gets unique credentials.) Yes No
    • When clients are unable to use authentication such as a client_secret, does the authorization server employ other means to validate the client's identity?
      • Requires registration of redirect URIs for clients
      • Involves the user in confirming the client's identity
      • Other:
      • No

    Client Impersonation (Section 10.2)

    • Does the authorization server provide the user with information about the client? Yes No
    • ... about the requested scope? Yes No
    • ... and lifetime of the request? Yes No
    • Describe the security measures taken to ensure repeated authorization requests come from the original client and not an impersonator:
    19 likes 6 reposts 3 replies 5 mentions
    #oauth #oauth2 #standards #web #authentication #checklist
  • [OAUTH-WG] OAuth Status (www.ietf.org)
    #oauth #oauth2
  • Top 5 OAuth 2 Implementation Vulnerabilities (intothesymmetry.blogspot.ch)
    #oauth2 #security
  • Into the symmetry: Beware what you click (intothesymmetry.blogspot.ch)
    #oauth2 #security #github
  • OAuth 2.0 and Sign-In (www.cloudidentity.com)
    OAuth 2.0 is not a sign-in protocol. Sign-in can be implemented by augmenting OAuth, and people routinely do so...
    #oauth #oauth2 #authentication #internet