23 Matching Annotations
  1. Oct 2019
    1. OAuth can be many things. It is most commonly used to allow an application (the consumer) to access data or services that the user (the resource owner) has with another service (the provider), and this is done in a way that prevents the consumer from knowing the login credentials that the user has with the provider
    1. For each call to your API, user should send token with every API request and you should validate the encoded toke and either deny or send back the response.
    1. Application credentials provide the required information about the caller making a request to a GCP API. Valid credential types include API keys, OAuth 2.0 client credentials, or service account keys.
  2. Sep 2019
    1. it's not that there are new vulnerabilities that have been identified in the implicit flow, just that PKCE offers a more secure alternative that you should use if you have the option

      Use PKCE instead of the implicit flow if you have a chance

    2. PKCE (which stands for "Proof Key for Code Exchange" and is pronounced "pixie") was originally developed to solve a problem specific to native mobile apps using OAuth 2.0

      PKCE (Proof Key for Code Exchange) is an extension to OAuth 2.0

    3. While this has worked and continues to work for a wide range of web applications, security experts had (and continue to have) concerns that it leaves open some potential attack vectors

      Implicit flow is still simple and very secure

    4. click a button that says "Sign in with GitHub." I am then sent to GitHub to sign in and, if this is my first time, grant permissions

      The Implicit flow:

      1. The application requests authorization from the user ➡
      2. The user authorizes the request ➡
      3. The authorization server issues an access token via the redirect URI ⬅
      4. The application uses the token to call the API ➡
  3. Mar 2019
    1. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client

      I wonder why this ID must be "unique and never reassigned...within the Issuer". This effectively makes it a trackable ID if clients work together.

      What would break if this ID is unique within the (Issuer, client) combination.

  4. Oct 2018
  5. Sep 2018
  6. Jul 2017
    1. o ensure that the "redirect_uri" parameter is present if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical.
    2. If an authorization request is missing the "response_type" parameter, or if the response type is not understood, the authorization server MUST return an error response as described in Section 4.1.2.1.
    3. The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. If the issued access token scope is different from the one requested by the client, the authorization server MUST include the "scope" response parameter to inform the client of the actual scope granted.
  7. Jun 2017
    1. This should only be one per client as each grant type has different security properties and it is best to keep them separate to avoid mistakes.
  8. Apr 2016
    1. A delegated solution means that one site is simply outsourcing its authentication needs to another pre-selected site. If your site uses Facebook Connect, you are delegating your authentication facilities to Facebook. Visitors to your site cannot use any other accounts, only accounts from the vendors you have pre-selected. A federated solution means that visitors to your site can use any account they have, as long as it is compatible. It makes no difference to the site which account is being used, as long as it can interoperate. At its core, OpenID is a federated solution because its most important feature is the ability to use any OpenID account with any OpenID-enabled service. A good example is stores accepting credit cards. A store that accepts any Visa card is using federated payments – payments from any account that “speaks Visa”. But a store that accepts only credit cards issued by a specific vendor, for example, a department store branded card, use delegated payments. The reason why you no longer see many stores accepting only their own credit cards, is because it is bad for business. But not every OpenID implementation is federated, and this is the big dilemma OpenID has to resolve. The question is, can users use any account they want? If a site uses the Yahoo! OpenID service by using the Yahoo! button: but does not offer the ability to use other vendors, it is really just another delegated solution, even if it is powered by OpenID under the hood. In this case, OpenID becomes just a technical detail of the implementation, not part of its design. Much of the recent discussion about OpenID usability centers around using brands as a way to make the service more usable. But the problem with this approach is that is takes away most of the federated value out of OpenID, leaving it simply as a common protocol to implement proprietary delegated services. When implemented this way, OpenID adds no real value to services with an OAuth API. The question which solution to use for sign-in, OpenID or OAuth, is very much application specific. If you are building a brand new site that needs accounts, and want to leverage existing accounts from services such as Google, Yahoo!, and Microsoft, OpenID is a great option that will give your users a lot of flexibility. But if you are extending an existing service, implementing a specific API and building a site that has great dependencies on another service, OAuth gives you everything you need, for very little extra work. It is all about using the right tool for the job.
  9. Jun 2015
  10. May 2015
    1. Last week we talked about giving away your passwords and how you should never do it. When a website wants to use the services of another—such as Bitly posting to your Twitter stream—instead of asking you to share your password, they should use OAuth instead. OAuth is an authentication protocol that allows you to approve one application interacting with another on your behalf without giving away your password. This is a quick guide to illustrate, as simply as possible, how OAuth works. The Actors There are 3 main players in an OAuth transaction: the user, the consumer, and the service provider. This triumvirate has been affectionately deemed the OAuth Love Triangle. In our example, Joe is the user, Bitly is the consumer, and Twitter is the service provided who controls Joe’s secure resource (his Twitter stream). Joe would like Bitly to be able to post shortened links to his stream. Here’s how it works: Step 1 – The user shows intent Joe (User): “Hey, Bitly, I would like you to be able to post links directly to my Twitter stream.” Bitly (Consumer): “Great! Let me go ask for permission.” Step 2 – The consumer gets permission Bitly: “I have a user that would like me to post to his stream. Can I have a request token?” Twitter (Service Provider): “Sure. Here’s a token and a secret.” The secret is used to prevent request forgery. The consumer uses the secret to sign each request so that the service provider can verify it is actually coming from the consumer application. Step 3 – The user is redirected to the service provider Bitly: “OK, Joe. I’m sending you over to Twitter so you can approve. Take this token with you.” Joe: “OK!” <Bitly directs Joe to Twitter for authorization> Note: This is the scary part. If Bitly were super-shady Evil Co. it could pop up a window that looked like Twitter but was really phishing for your username and password. Always be sure to verify that the URL you’re directed to is actually the service provider (Twitter, in this case). Step 4 – The user gives permission Joe: “Twitter, I’d like to authorize this request token that Bitly gave me.” Twitter: “OK, just to be sure, you want to authorize Bitly to do X, Y, and Z with your Twitter account?” Joe: “Yes!” Twitter: “OK, you can go back to Bitly and tell them they have permission to use their request token.” Twitter marks the request token as “good-to-go,” so when the consumer requests access, it will be accepted (so long as it’s signed using their shared secret). Step 5 – The consumer obtains an access token Bitly: “Twitter, can I exchange this request token for an access token?” Twitter: “Sure. Here’s your access token and secret.” Step 6 – The consumer accesses the protected resource Bitly: “I’d like to post this link to Joe’s stream. Here’s my access token!” Twitter: “Done!” Recap In our scenario, Joe never had to share his Twitter credentials with Bitly. He simply delegated access using OAuth in a secure manner. At any time, Joe can login to Twitter and review the access he has granted and revoke tokens for specific applications without affecting others. OAuth also allows for granular permission levels. You can give Bitly the right to post to your Twitter account, but restrict LinkedIn to read-only access. OAuth Isn’t Perfect…Yet OAuth is a solid solution for browser based applications and is a huge improvement over HTTP basic authentication. However, there are limitations, specifically with OAuth 1.0, that make it far less secure and less user-friendly in native and mobile applications. OAuth 2.0 is a newer, more secure version of the protocol which introduces different “flows” for web, mobile, and desktop applications. It also has the notion of token expiration (similar to cookie expiration), requires SSL, and reduces the complexity for developers by no longer requiring signing.
  11. Mar 2015
    1. Satellizer is a simple to use, end-to-end, token-based authentication module for AngularJS with built-in support for Google, Facebook, LinkedIn, Twitter, Yahoo, Windows Live authentication providers, as well as Email and Password sign-in.