Does Google plan to support the Form Post response mode in its OpenID Connect/OAuth 2.0 implementation?
http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html
Other identity providers such as Azure Active Directory and IdentityServer support this, but it seems Google doesn't (based on reading the docs and some manual testing). For context, I'm building an OpenID Connect library and was hoping to leverage this capability (and prefer not to rely on acquiring tokens via HTTP GET and URL fragments).
This does appear to work when you pass ?response_mode=form_post to google... but I can't find it anywhere in their documentation. :shrug:
Related
I am building a static application aiming for zero-costs apart from static content distribution, and for potential user interaction would like to embed a service which allows versioned edits to embedded content. Ideally, I would have liked to have used github, for instance to submit content directly from specific pages, but github uses OAuth 2.0 which would require some kind of backend process. Google and FB have web logins but the types of content embedding they provide aren't particularly useful (unless I am mistaken).
My question is what other options are out there that might provide git-based embedded content. Ideally not bloatware.
Just to stress that I am not interested in any kind of service like Cognito or Firebase or oauth.io.
Well, I strongly believe that you discarded the OAuth2 provider too soon. And, I might say, you do not need a backend to use an OAuth authenticator.
OAuth2 has some "flows" you can choose from. The most common demands an backend, since its authentication uses a refresh token to renew the access tokens and your backend should do that. You can find a good start point about the flows here:
https://auth0.com/docs/api-auth/which-oauth-flow-to-use
In your case, I believe you are looking for Client Credentials Flow (or the Resource Owner Password Credentials Flow). Particularly, from the context I got, I would recommend you to seek the Client Credentials Flow. This flow do not have a Refresh Token and you can authenticate your application just from a client perspective (running on a browser, for instance) and do not require any backend service. Most of OAuth2 providers supports this flow. What happens in this flow is that every time the client reloads or access your site and the access token is expired it will re-authenticate via the OAuth provider (or you could even automatize this and add some transparency to your client). A little bit more:
https://nordicapis.com/8-types-of-oauth-flows-and-powers/
Hope it helps!
I have Angular 2 application which talks to the Web API and does some basic CRUD operations. I have few questions:
Is any way I can create a Login/Register page on Angular 2 using ASP.NET Identity?
How do I manipulate with a data only relates to the logged in user? (Token Based Authentication? How it works? Where to read about it?)
How can I implement login/register process on actual Angular 2 application without redirecting me to Identity Server?
I looked at IdentityServer4, OAuth2 and OpenID examples, it is a bit too complex to understand. I went thru every single step in quick start, it works but I don't understand how and what it does.
Can someone give me any resources where I can start from? Blogs, websites, books, step-by-step guides.
You're correct that at this point the most comprehensive solutions for authentication and authorization in systems that rely heavily on HTTP are based on OAuth 2.0 and OpenID Connect. This of course includes your specific scenario of a SPA calling a Web API back-end. For further read on this generic case you can check the Auth0 SPA + API Architecture Scenario or give a look at the quickstarts focused on your selected technologies:
Angular2 Quickstart
ASP.NET Core Web API Quickstart
Note: Auth0 supports OAuth 2.0/OpenID Connect so even though the docs may have additional features that are provider-specific, you may find them useful if you do indeed decide to go the OAuth 2.0/OpenID Connect route. It's one of the advantage points of relying on standards, it's easier to switch between implementation/providers.
However, you should also consider if you really need to go full OAuth 2.0/OpenID Connect as they aim to solve a lot of different use cases and as such also bring significant complexity with them. If you go that route, it's recommended that you leverage existing libraries like IdentityServer or cloud providers like Auth0, because doing your own implementation carries a lot of risk and requires significant effort.
In order to meet your requirement of providing an integrated login from within your own Angular2 front-end you could probably look into the resource owner password credentials grant specified by OAuth2.
Another alternative is doing your own custom solution, this is generally frowned upon, because it's easy to get wrong, but the theory would be:
Handle user authentication and registration (possibly using ASP .NET Identity)
Upon login exchange user credentials with some a token that you can later use to call into the API
The token could just be a random (not guessable) value used as a reference to some server-side storage that would contain information about the associated user.
Well, I have an angular.js client and a WebApi Server. I want to use OAuth 2.0 authorization of Microsoft and I just can't understand how I should get the answer from the http get request to the /authorize endpoint and why when I try to make the request I get a CORS problem?
Check Authorize access to web applications using OAuth 2.0 and Azure Active Directory. It worked for me along with simple-oauth library.
Make sure that you totally understand what exactly authorization endpoind you need. I've started with Oauth 2.0, but then I realized that new v2.0 endpoint is better way for me with this tutorial for angular and workflow explanation:
In the past, an app developer who wanted to support both Microsoft
accounts and Azure Active Directory was required to integrate with two
separate systems. We've now introduced a new authentication API
version that enables you to sign in users in with both types of
accounts using the Azure AD system. This converged authentication
system is known as the v2.0 endpoint. With the v2.0 endpoint, one
simple integration allows you to reach an audience that spans millions
of users with both personal and work/school accounts.
And keep in mind that Live APIs are deprecated:
The Live Connect APIs are deprecated. We recommend that you use the
Outlook REST APIs to build your solutions. This will extend your reach
to Outlook.com users and Office 365 enterprise customers. Although the
Live Connect APIs will be supported in Outlook.com for the short term,
existing Live Connect API solutions might stop working without
advanced notice. If your app is using IMAP with OAuth 2.0, it will
continue to work, but our REST APIs are the primary APIs for building
apps that connect to Outlook.com and Office 365. Read the article on
how you can take advantage of the Outlook REST APIs.
I've been trying to integrate OAuth2 authentication in my drf application. Given I don't yet need a front-end for my app, I was using the browsable API. DRF and the OAuth2 provider package are supposed to work together without much configuration, as explained in the tutorial.
I should mention that all the steps from the tutorial are working (so I can access the app from the command line) but when I try to do it from the browsable API, I don't see any request for an access token or anything like that.
I think that DRF does not actually provide the flow for the front-end part of authentication by OAuth2, but I was just wondering if someone managed to make it work (because for now I am using SessionAuthentication).
Thanks.
OAuth2, unlike basic authentication and cookie-based authentication, does not easily work within the browser. When authenticating requests, it relies on the Authorization header being present (with the OAuth type) and there is no way using a browser to easily fill that in.
Session authentication relies on cookies, which most browsers easily support, and is recommended for interacting with APIs that are on the same domain as the front end.
Basic authentication also relies on the Authorization header, but uses the Basic type which is supported by most browsers.
The old Google OpenID endpoint provided a way of authenticating users without having to register your application first. This was very convenient for open source applications because they could provide a "log in with Google" option which would work out of the box. For instance, Google's own code review tool Gerrit makes use of this.
It appears that this endpoint is deprecated and will be shutdown:
https://developers.google.com/accounts/docs/OpenID2
My question is twofold:
Is the endpoint that's going to be shutdown the one at https://www.google.com/accounts/o8/id used by StackOverflow, Gerrit etc.? (With all the different OAuth and OpenID variants mentioned in Google's docs, it's not terribly clear.)
If so, is there any non-deprecated login option that doesn't require the application to be registered.
Indeed OpenID2 is deprecated, and that is the endpoint at https://www.google.com/accounts/o8/id;
Open-Source code can still be written; it will require just that the site integrating the open-source solution perform the registration step and supply the registration values (client_id, redirect_uri) to the open-source code. If you write the code with a modular approach to configuring the registration data, the code can be highly re-usable.