I need to authenticate users via LinkedIn, Vkontakte and other social networks that do not have providers yet.
I succeeded creating custom authentication provider in the following way:
Get code for Facebook provider in Katana source code.
Change all "Facebook" to "Vkontakte" (just find&replace).
Customize [provider_name]AuthenticatedContext class, [provider_name]AuthenticationHandler.ApplyResponseChallengeAsync() and [provider_name]AuthenticationHandler.AuthenticateCoreAsync().
Everything works well, but just wondering. Much code is duplicated with no actual change. Is there a way to use any standard stuff for building custom provider, not just copying the files?
Unfortunately not. I also created new providers for LinkedIn and Yahoo and even though I copied much of the code from the Katana project there are little nuances with each provider which means you cannot really use a single code base for all.
BTW, you can check out the LinkedIn and Yahoo providers at http://www.beabigrockstar.com/introducing-the-yahoo-linkedin-oauth-security-providers-for-owin/
Related
I'm currently trying to add google sign-in support to our educational website. The majority of time users will just sign in with Google, but occasionally teachers need to be able to import pupil rosters from Google Classroom too. I've got all of this working using the guides from the Classroom developers site (https://developers.google.com/classroom/quickstart/js). I'm using https://apis.google.com/js/api.js to sign users in (gapi.auth2.getAuthInstance().signIn) with just the "profile" scope and then granting the extra classroom scopes if teachers need them.
I'm just reading the Migrating to Google Sign-In guide (https://developers.google.com/identity/gsi/web/guides/migration) and trying to work out if it applies to us or not. It's explicitly saying not to use gapi.auth2/gapi.client etc anymore and to use the new Identity Services Library instead, but there's no explanation how to use that to make API calls to Classroom (or any other Google API). The OAuth 2.0 JS guide (https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow) is still saying to use gapi.auth2 etc too.
So should I be using the new library to sign users in, instead of api.js?
And if so, am I still supposed to be using gapi.auth2 to make API calls, or should I be using the new library instead somehow?
Authentication for sign-in, and authorization for data access are being separated. Use the new Identity Services library for sign-in instead of api.js and the profile scope. This should be the case for the majority of your users based upon what you've shared.
Later, and as needed, continue using gapi.auth2 to obtain an access token and call the Classroom or other Google APIs.
Functionally, what this will look like is separating out your sign-in flow using HTML or JavaScript from gapi.auth2 and access/refresh tokens. Token requests for calling APIs (using either implicit or auth code) would be made only at the point they're needed. Say you'll use 3 different scopes at some point, each would be requested only when necessary, also known as incremental authorization.
I/we at www.dr.dk are working on a Sonos integration with the bare minimum functionality. This means that we wish to apply anonymous access in this first version of our Sonos integration.
In the API documentation
https://musicpartners.sonos.com/node/289#toc0
is says 'Finally, you can decide not to use any authentication, also knows as anonymous access. ...'
Which we read as an option to not to implement authentication endpoints like 'GetAppLink(...)' etc.
So now we have teste our service and it appears to work fine, as far as we know. Therefore we have now started to fill out the application registration form.
In the registration form we find the following required fields regarding authentication as depicted in the image below
Screenshot from the application registration form
As we see it these fields are related to authentication and seems somewhat confusing to us. So with our logic - anonymous authentication means that no test accounts or customer care accounts are needed etc.
So the question is. What are we missing ?
You can just mark those as N/A for each of the fields.
I want to create a custom API that behind the scenes, call number of other APIs which use OAuth 2.0 for authentication. I want to manage this internally so that my custom endpoint somewhat abstract this.
Or to begin with I want to do what app like buffer (https://buffer.com) do - where you connect to different social services and than post your status.
How can I achieve this in .NetCore ?? I don't want to login with these (a lot of samples are catering this scenario), user login is different than this. I just want to establish these connections (like API Connections if you look at Azure API Management) and then perform some operations against those endpoints.
I hope i convey my point. please let me know if this isn't clear.
Thanks
Sanjay
OAuth2 systems are all based on the same workflow.
here's an authorization url, you pass some ids in an authorization header, if everything is correct you get a token, you then use the token to do whatever you are allowed to do. What changes are the credentials you use for authentication and the urls you hit for the various parts of this workflow.
You could write your own OAuth2 library which deals with all this, that's pretty much what I did and simply changed the details for every specific system I had to interact with.
This being said you can always use one of the existing implementations to connect to the various systems you care about, they all have an API you could use, all you have to do is make sure you follow the OAuth2 flow correctly.
I have a JSON REST API written in Symfony 2.7, and I want to authenticate & authorize users. This is my first time doing this, so I have some doubts/questions.
For that, I thought several methods:
User & password, and then save a session in the back end
Same as 1), but add an "apiToken" (randomly generate when user register) and then sending back & forth the apiToken in every single request to check user identity.
Use OAuth (which I'm currently reading about it).
I read that using OAuth for a simple API is like an "overkill", but on the safe side it sticks to standards and also allows me to use it when using my API with mobile devices and different platforms.
Also, I don't know too much about security flaws of using method 1) or 2).
I know this is maybe based on opinions, but I don't know any other site to post this question, as Symfony official mailing was shut down and migrate here it seems.
As you seems to know, your question is too opinion based.
If I can give you some advices (too long for a 600chars comment),
OAuth is powerful, but so much free.
I mean that you can easily implement it sort as everything works well while having a set of potential security issues without being aware of their existence.
Libraries and bundles providing OAuth are hard to maintain because of the new security issues regularly found.
On the other hand, if you need the benefits of OAuth (be a client and/or a server, compatible with the most part of social networks), go learn OAuth and do your experience with it.
Otherwise, use a simple credentials/request token two-step authentication.
See the JWT Authentication tutorial by KnpLabs,
Symfony Guard Authentication by Ryan Weaver,
and the great LexikJWTAuthenticationBundle, easy to implement and to use.
I am just getting started using DotNetOpenAuth with an MVC app and I am having it a bit difficult understanding how it actually works.
As far as I understand, DotNetOpenAuth will take care of authenticating a user with Google/Twitter/Facebook (probably after some modification).
What happens afterwards? Is the user authenticated per request? Is the user information saved in a session using IPrincipal, IIdentity? How does it fit together with an MVC application which will store all user information in the application database (custom tables and not the default .NET membership provider ones)?
Also, if you know any good tutorials, documentation on the subject, please share this as well.
Thanks!
DotNetOpenAuth only deals with the authentication step -- how you decide to store and recall that authentication ticket is up to you. It is very common to use FormsAuthentication to log the user in:
FormsAuthentication.RedirectFromLoginPage(authResponse.ClaimedIdentifier);
Using this approach, a cookie is sent to the browser and comes in with every request -- just like if you had used the older username/password approach.
You can download a bunch of samples from SourceForge.