This question already has an answer here:
Automatic Login from one web site to Moodle web site?
(1 answer)
Closed last year.
I have an user details stored in my web site database and Moodle database. I logged my website with that credentials , Moodle also auto login with that credentials is there any way? Or any Code is available?
If you're handling credentials correctly (and Moodle does), you DO NOT STORE THE ACTUAL PASSWORD! Instead, you store a salted hash of the password.
When someone tries to log in, you salt and hash the attempted password using the same salt and hashing algorithm. This will give you the same result as the value in the database, and so instead of comparing passwords directly you now compare hash values. In this way your users are protected from having their passwords leaked if someone breaches your application.
If you're not doing it this way on your own site, you're doing it WRONG and need to fix it ASAP. This is big deal!
Here's the thing: the two web sites aren't necessarily using the same hashing algorithm, and certainly aren't using the same salt. Therefore the user credentials you have saved for your web site are NOT the same credentials saved in Moodle, even if all the users have the same password.
But what you're really asking about is SSO (single-sign-on). There are (safer!) ways to support this. SAML, CAS, Shibboleth, and OAuth come to mind, and Moodle definitely supports these. You can also have Shared (as opposed to Single) Sign-On, where both your app and Moodle use a third party such as AD or LDAP for identity verification, so the username/password credentials are the same but you still have to sign into both applications separately.
Unfortunately, you will need to build this into your own app, as well, and perhaps even add an additional authentication portal server to your organization to act as the trusted intermediary between each of these applications. There are a number or products you can use, including some that are open source or may already be included with other licensing, so you don't have to start from scratch or necessarily make an expensive purchase here.
The good news here is these products generally also put you into a good position to start supporting Multi-Factor Authentication, which is also an important feature to provide.
Related
I understand JWT can be used to authenticate a user but not much info seems to available on how you can secure the connection between frontend and backend api to ensure the website is not a fake duplicated used to lure users and steal their creds.
Maybe I'm just not wording my searches properly or understanding the topic, but how would you ensure that the client trying to connect to your API backend is authorized to and denied if it's not, even if the correct creds are used? This is for JWT.
I know it can be secured using API keys but this question is specific to JWT.
There isn't a great deal you can do against social engineering attacks. If data is sensitive then giving users regular warnings about how people might try to trick them with fake websites is fairly common.
Wikipedia lists a number of techniques that can be used to customise the UI to make it easier for the user to recognise that they are on the right site.
2 factor authentication can also help. While incorrect credentials could result in a token being passed to the attacker (allowing them access to the site), it will expire after whatever time limit you put on it and they will need to refresh it or be unable to reuse the password (since they won't have the new 2FA code).
You can also monitor for logins from large numbers of different users from the same IP address.
I am reading about oauth2 now, and trying to understand its purpose. From all the resouces I read, it seems like oauth2 is only used when a webapp (say a game app) that has some users and the app wants to access a user's Facebook or Google data (some sort of data such as name or email, etc). This part is clear to me. However, things that remain unclear to me are the following:
For example: If I have a webapp, and I want the users of my webapp to log into the webapp with their login and passwords (just like how you do it with gmail) without using any third party. Does oauth2 also serve this type of authorization?
I have seen webapps, where they just let users sign up with IDs and passwords, then they salt the passwords and store the salts in the database. So when a user logs in later, they salt the password the user entered, and compare this salt to the salt in the database (created during the signup). If equal, then the user logged in. This does NOT seem like oath at all to me. So if this is not oauth, what standard is this? And are there any other standards for "direct login" like this?
Assume that I want to allow users to sign up and log in to my website, but let them log in via a third party (like Facebook or Google). This is just for authorization purposes and assume that my app has no plan to post on their facebook or request their facebook data except that I may want to use their facebook email as the user ID for my webapp. Does oauth2 serve this type of authorization?
Sorry for the naive questions, because I only read about oauth recently.
For sign-up/login without 3rd-party, as Kevin pointed out, each programming/web framework usually comes with a popular library that once, it will generate all the sign-up/login pages, database tables, flow, etc., for you. The only thing you then do is call a method provided by the library that returns the current signed in user, in your backend code when you need to figure out who the user is.
Using salted password scheme is NOT related you OAuth2 at all as you pointed out. It is a widely used scheme for local authentication because it has many benefits but I will just highlight 2 here:
a. A password when transmitted from user to server for authentication over the Internet is not sent in cleartext but rather in hashed format. Thus even if it were eavesdropped, the password will not be divulged.
b. Since each password is salted, even 2 same passwords will not have the same hash because each have different salt. Thus even if a password hash was eavesdropped, it cannot be reused at another service that the user uses the same password because the other service expected a password hash generated with a different salt.
OAuth2 is all about Authorization (asking a user for permission to perform something on her behalf at another web service, e.g., ask a user for permission to access her email address registered on Facebook). Using it for Authentication can be insecure (for OAuth2 implicit flow). Why? The end result of OAuth2 is an access key associated with a permission, e.g., 'permission to access email address'. When you use the OAuth2 result (access key) for authentication, it means that you are making the assumption that 'permission to access email address' means the user successfully authenticated with Facebook, which she did, so it seems fine. However, imagine if another site also uses OAuth2 for authentication as you did; if it receives an access key with 'permission to access email address' it will assume that you have authenticated with Facebook so it will grant you access to the account belonging to the email address. You could actually use the access key you got from a user, and login as her in the other site, and vice versa.
To use OAuth2 for authentication, you need to use it with OpenID Connect (OIDC), because the end result of OAuth2-OIDC contains an id_token with the aud (audience) field identifying who the access key is for (https://openid.net/specs/openid-connect-core-1_0.html#IDToken), which prevents the access key from being reused where it is not intended. The full explanation with easy-to-understand diagrams is here: https://www.slideshare.net/KhorSoonHin/the-many-flavors-of-oauth/36?src=clipshare
Another very simple but perhaps unnerving to a security-conscious way to do use OAuth2 for login is to use the Resource Owner Password Credential, where your website acts as a middle-man between the user, and OAuth2 provider (Facebook).
Show 'Login with Facebook' button
When user clicks on button, prompt user for Facebook username/password
Use the username/password to login to Facebook to confirm authentication and get access token.
If you don't have to time to read in-depth about OAuth2, perhaps this side-by-side comparison of all the OAuth2 flow can help.
This is courtesy of https://blog.oauth.io/introduction-oauth2-flow-diagrams/
You could use OAuth for local logins like this, but you don't have to. It might be easier, depending on available libraries, and it might make sense if you anticipate making your service available to third-parties in the future. For many sites, though, using OAuth for local logins would be overkill.
Standards are most useful when different actors need to speak a common language so they can interoperate. For local logins you don't need a standard because you're not interacting with any third parties. Many web frameworks include their own variation on the same basic flow.
I think you're asking whether OAuth makes sense for authentication (establishing identity) when you don't actually need any authorization (permission to access third-party resources). It can indeed be used that way, but lots of people will warn against it since it wasn't designed for that and has some security weaknesses in that context. See, for example, Common pitfalls for authentication using OAuth.
I'm developing an application where Google Drive will be used to manage some documents. The idea is to create a document with some initial template data and provide the users access by adding them as collaborators of the document.
I'm familiar with the OAuth authentication process, I used it in another part of the system to manage the users Calendar...
But in this case these documents will be stored in a generic account of the company, so I can't have the approval prompt for authentication, since users won't have the password of the account.
I'd like to directly authenticate in this account, could be with the username and password hardcoded in the Java code.
Problem that this method of authentication was depreacated and I didn't found a relpacement.
Any ideas?
Thanks in advance,
Phillip
There are 2 ways that comes to mind:
Service accounts: best suited for server side OAuth with traditional backend
Regular Account owned by the application : similar to the process already in place for client side Oauth that you are already familiar with; Auth, store the refresh, ask new token if the AuthCode is expired, and so on.
I personally use and prefer the second solution more as I feel is more flexible to adapt in the future for Oauth Client Side get the tokens and use them server side.
So a bit of background, I'm working on an existing web application which has a set of users, who are able to log in via a traditional login screen with a user name and password, etc.
Recently we've managed to score a client (who have their own Intranet site), who are wanting to be able to have their users log into their Intranet site, and then have their users click a link on their Intranet which redirects to our application and logs them into it automatically.
I've had two suggestions on how to implement this so far:
Create a URL which takes 2 parameters (which are "username" and "password") and have the Intranet site pass those parameters to us (our connection is via SSL/TLS so it's all encrypted). This would work fine, but it seems a little "hacky", and also means that the logins and passwords have to be the same on both systems (and having to write some kind of web service which can update the passwords for users - which also seems a bit insecure)
Provide a token to the Intranet, so when the client clicks on a link on the Intranet, it sends the token to us, along with the user name (and no password) which means they're authenticated. Again, this sounds a bit hacky as isn't that essentially the same as providing everyone with the same password to log in?
So to summarise, I'm after the following things:
A way for the users who are already authenticated on the Intranet to log into our system without too much messing around, and without using an external system to authenticate, i.e. LDAP / Kerberos
Something which isn't too specific to this client, and can easily be implemented by other Intranets to log in
Both of your suggested options are insecure, even if you use SSL. Never pass credentials on a URL, put them in the HTTP request by using POST.
There is a standard called SAML and this can be used to solve your problem. The challenge is choosing which version to implement. I would choose SAML 2.0.
Google Apps implements a flavor of SAML 2.0 and allow you to authenticate using your intranet credentials. In the case of your application, you would be the service provider and your client would be the identity provider. As long as you implement the standard correctly you should be able to support any new client (identity provider). Here is a list of SAML implementations you might want to take a look at. If you need the client to pass over information in addition to the authentication information then SAML can facilitate this with metadata.
You will still need to implement SSL to encrypt network traffic.
I hate to answer my own question, but I hate even more a question with no answer. In the end we went with a very similar implementation of SalesForce's delegated authentication SSO implementation.
http://wiki.developerforce.com/page/How_to_Implement_Single_Sign-On_with_Force.com
Essentially the solution has a trusted site, known as the delegated authentication authority, who has a list of users who are logged into the company intranet.
When the user logs into the company intranet, and they click a link to our application, the company intranet will pass the user name and a generated token (which expires after a set amount of time) to our application.
Our application will then check if the user name is on our site, and if so, send the username / token (along with the source IP and a few other parameters) to the delegated authentication authority. If all those items match on the delegated authentication authority, it returns true and the user can log in. If it returns false the user is denied access.
We've found this system to work quite well, and even implemented a couple of extra security features like SSL, client side certificates, VPN tunnel, and even restricting the IP addresses which can access the site and the delegated authentication authority.
I know it's bad form to answer your own question but I hope this helps someone else who might be having the same problem ...
Here's something similar to this question on general SSO best-practices. What is the best approach for dealing with a disabled or for-whatever-reason-unreachable central identity provider. If your website allows users to login with their centrally-stored credentials, and the central service is not working or unreachable do you:
Allow users to re-enter their credentials on the local site, so that they can use the native login facility of the web application (or content management system or whatever)
Allow users to request another secondary set of credentials that they can use on the web application itself (i.e., a separate password they can use when the IDP is down) [NOTE: obviously this defeats the 'single credentials' goal just tossing out all ideas].
Allow the users to login using any of several various maintainers of the same credentials (by giving them multiple links to multiple providers, and then trying each one of them until one of them actually connects and works)
For probably apparent reasons, none of these solutions above seem attractive, so feel free to put these on the "worst practices" list while you answer with the best alternative approach.
I'd think the best way would be to have decentralized SSO, as is implemented in Open ID. If each account can have many providers, then if one provider goes down, you can fail over to another.
On the other hand, if centralized SSO is required. The only thing that I can think of would be to have the central authority generate a cryptographic certificate for each user. If the service has a fresh copy of the certificate revocation list and a cached copy of the central authority's public key, it can validate certificates even if the central authority is unavailable. Unfortunately, this method would probably suffer from usability issues as users would need to both keep a copy of their certificate handy and know what you're talking about when you ask for it.