browsing in this website, i found some interesting suggestions. SocialAuth.net and DotNetOpenAuth.
i started using SocialAuth. It's very simple to use and it worked (i only tried with google so far thou). My only problem with this library is that it doesn't provide a way to retrieve the Contacts from the providers it offers without logging you in with the new (or latest) provider you requested the list of Contacts.
in other words, i MUST sing in my people with a local username and password for security reasons. BUT i would like to benefit from this library's feature of getting contacts from different providers. Thing is that it overrides my currently logged in user (using FormsAuthentication) for the Authentication Token sent by google.
Has anybody confronted this issue?
Does DotNetOpenAuth doesn't have this flaw?
Thanks
Are you sure you understand OAuth?
It could be that I misread your question, and to be honest I don't have any experience with socialAuth.net (will look into it).
To me it seems like you think socialAuth.net requires you to login, I know this is not the fact in DotNetOpenAuth. Only place you need to login (if you aren't already) is the service you are connecting with (Twitter, Facebook, etc.)
Of course it could also be I just answered your question :D
Maybe you should check the last changes in source:
http://code.google.com/p/socialauth-net/source/list
As you can see, in r320 it seems they have fixed this issue
Related
I manage a couple of older webapps that at some point have been converted to Laravel. They both allow login via email/password combinations or FaceBook logins, using Socialite for the latter.
FaceBook has advised me I need to confirm I meet the requirements for:
[A] Enforce encryption at rest for all Platform Data storage (e.g., all database files, backups, object storage buckets)
More clarification has not been forthcoming, and FB docs for developers tend to be self-referencing without really being clear. The inference here seems to be that any data provided by FaceBook via their API must be encrypted in the DB.
This can partly be achieved through casting certain User attributes to "encrypted" and applying this to the DB fields retrospectively for existing FB and non-FB users. However I don't see any obvious way of encrypting email address and still being able to use Laravel authentication in any fairly standard way. I can see how it could be made to work, though solutions seems to be onerous and rather awkward
As I find Laravel tends to offer straightforward ways of achieving routine functionality, and I don't think providing email/password logins is especially unusual, I'm surprised to find no information at all about how to work around this.
Am I mis-understanding the requirements here? Are others in a similar position not coming across these Data Protection Assessment requirements, or are they just telling FB "sure, everything's as it should be" and applying their own standard of security to user data?
I don't think this is off-topic or too vague, but appreciate it might be. If the question stays up, any advice is welcome.
Thanks
Edit:
Moved to github Laravel discussions
https://github.com/laravel/framework/discussions/42397
If you examine firebase cms, you will understand better what you mean.
must be talking about encryption of repositories like automatic backup.
I am writing an app that uses Parse Server, with Auth0 as the authentication provider. For unrelated reasons, we need to use Auth0 rather than Parse for user management.
I'm having trouble figuring out how to "link" a user authenticated via Auth0 to Objects in Parse Server. Without this, the authenticated user will not have permission to write to his/her Objects on the Parse Server. I believe my issue is similar to this question, which has no solution: here.
I have found many articles discussing the migration of users from Parse to Auth0, but am finding surprisingly little documentation on how to link those users to Parse. There is one article (I believe written by the same person who posted the question I linked to), but I couldn't get it to work, and it involves storing passwords in cleartext in Javascript.
I thought to create a default Parse user that would simply own all the objects in Parse. This would be invisible to the authenticated end-user so they wouldn't know, but that's just security by obscurity and doesn't seem like a good approach.
If anyone has suggestions on how to approach this, or has done it before, I'm interested to read your suggestions. Thank you very much.
Auth0 supports the most common and used authentication protocols (OAuth2/OIDC, SAML and WS-Federation) so configuring an application to rely on Auth0 is really easy when that application already talks one of the previously mentioned protocols.
According to the Parse Server Wiki, it does support custom authentication leveraging OAuth so that seems your best starting point for integrating Auth0 with a Parse Server based application.
It is possible to leverage the OAuth support with any 3rd party authentication that you bring in.
Disclaimer: I never used the Parse service or Parse Server so I'm assuming that when you mean linking Parse objects to users this can be accomplished by simply having an authenticated user in Parse and the identity of that user is just verified and proven by Auth0 instead of something like built-in username/passwords managed by Parse itself.
With the new Codeigniter 3.0 version what authentication libraries do you use?
Flexi auth was very good and robust with great documentation for CI 2.0 but it is old and as I can see it is discontinued. Of course it does not work out of the box with CI 3.0. I have tested it and tried to migrate it to CI 3.0 but as it uses the old ci_sessions schema I have seen that it has a lot work to be made to rewrite all the code parts that use sessions. It seems to work with file sessions and some alterations on its code though.
Community auth has a CI 3.0 version but as I have seen, it has many bugs and it is nowhere near reliable at this time. I have tested it thoroughly and it cannot work properly as it has problems with its token jar system and its cookie management. Users cannot login most of the times and it is being used as a whole third-party library at Codeigniter, which personally I don't like as it has a lot of files/folders that are time consuming to be maintained. I would prefer simple CI libraries with 1-2 models like flexi-auth. Although, I wouldn't mind Community Auth's approach if it worked properly.
Tank Auth was a reliable solution in the past but not with Codeigniter 3.0 as it has many incompatibilities too. Questions about its compatibility with CI 3.0 were asked but no airplanes in the horizon so far.
DX Auth is an old authentication library and as I can see on its github repository, there are some attempts to migrate it on CI 3.0 but I haven't been able personally to test any of them.
So, has anyone successfully integrated (or migrated) any of the previous mentioned libraries on large CI 3.0 web applications? Did you write your own? Did you stick with CI 2 until further CI 3.0 development for that matter?
Update for the down votes
This post about Authentication libraries in codeigniter was very popular and helpful. I believe that posts that help the community in that way should not be closed at least not before some helpful answers. It is not discussed anywhere before and I would really like to see the opinions of more experienced developers for that.
don't let the down votes get ya down.
check out Ion Auth
https://github.com/benedmunds/CodeIgniter-Ion-Auth
take a look at the read me, you will have to rename two files for codeigniter 3. otherwise you can see that there are recent changes to the lib. the author Ben Edmunds is one of the four developers on the new codeigniter council. http://www.codeigniter.com/help/about
Please check Dnato System Login Its Simple, Fast and Lightweight auth codeigniter.
Feature:
-Add user
-Delete user
-Ban, Unban user
-Register new user sent to email token
-Forget password
-Role user level
-Edit user profile
-Gravatar user profile
-Recaptcha by Google
-And much more
Frontend
With Bootstrap Framework.
For a simple library, I use https://github.com/trafficinc/CodeIgniter-Authit (Authit). It is very simple so I can do a lot of customizations to it or just leave it be.
check this library.that is so nice.and with many features
login / logout
Login DDoS Protection
register and signup via email. (send verification code to your email)
users can send private message to other users
user group
create permissions and access control
error in other language
this library for CI2. but if you search about this, you can find lib for CI3
http://codeigniter-aauth-test.readthedocs.io
We have a .Net Web API (v2) serving an SPA that I aim to secure using OAuth 2.
In my OWIN Startup.Configuration(), I set my Provider in IAppBuilder.UseOAuthAuthorizationServer to an override of OAuthAuthorizationServerProvider. I have this successfully providing refresh tokens.
I want to be sure that these tokens cannot be spoofed by someone implementing a similar provider. No searching I have done has given me any kind of answer.
Does OAuthAuthorizationServerProvider ensure that the refresh tokens received are those issued by itself, and not any similar code on a hacker's machine?
My own experiment seems to confirm that it does - I tried the same code running on two different machines and took the unexpired refresh token (with a long expiry of 24 hours) from the other machine, and got a 401 as I'd hope. But just in case I've wrongly convinced myself, I'd like some reassurance and/ or advice from someone who knows more about OAuth in the .Net Web API than I.
Thanks,
Paul
I'm sure I eventually found a definitive answer in the doc for OAuthAuthorizationServerProvider but now can't find it.
However, Dominick Baier, an expert in this field, says:
Access tokens are protected using the machine key. Protection of refresh tokens is up to you. You need to manually set the machineKey element in web.config (otherwise the key gets auto generated and might change over time).
His comment comes from a reply to a post on implementing OAuthAuthorizationServerProvider.
I am trying to integrate two separate web applications - one is an existing custom web application with it's own security paradigm and the other is a reporting platform (JasperServer). I want to be able to use Jasper's web services interface to integrate the reporting functionality into our application. Our security model is complex and is home grown but I think there is hope.
We set a cookie that is an encrypted string containing a web service URI as the authentication source and a token which is stored in the database that is created when the user logs in and is destroyed when he/she logs out. I think I can leverage this to implement a kind of SSO in Jasper since it uses Spring Security.
What I THINK I should do is implement a pre-authentication filter that checks for the cookie I mentioned above. It could then decrypt it, make a web service call to the authentication source provided to verify the token is active in the database. If it is, that token can be used to point to user and role information that could be returned as a UserDetails object.
Unfortunately, I know enough to be dangerous but not enough to be effective. Am I on the right track? Does this solution sound tenable? If so, where would be a good place to start and are there any examples of something similar you could point me to? I've searched around quite a bit and have found nothing that quite fits the bill.
Thanks in advance to any and all who can provide me a glimmer of hope
Cookies are tied to a domain/subdomain/path and port. It is possible to set a cookie at the domain level so if you have something like webapp.mydomain.com and jasper.mydomain.com you may be ok assuming they are on the same port.
However be very careful about implementing your own SSO/Authentication framework. It requires a great deal of thought. As it stands your proposed implementation would be vulnerable to: replay, man in the middle, and XSRF attacks ... there may be other vulnerabilities but these are just 3 that come to mind ... sorry! :D