Background
Our customer wants their ASP.NET MVC application to use Yammer as authentication, and integration with comment-fields on the webpage. In other words, when you enter the site for the first time, you click "Sign-in with Yammer", get redirected to Yammer login, allow the App access, and there you go. For this, the customer has created an external Yammer-network, so that everyone who's a part of this network, has access to the site. This should also work for external consultants, not in our customer's home network, but in our customer's external network
The App is registered in our customer's Yammer-solution (home network), and deployed.
The problem
People from our customer's home network, who also are included in the external network, has access to the site. The way we do this is to first get the user's access token (for the home network), then do a look-up in the /api/v1/networks/current.json endpoint to see if he is in the correct external network, then use the /api/v1/oauth/tokens.json endpoint to get the access token for that specific external network.
This works fine for end users from inside the customer's home network. However, for external clients, this does not work all too well. It seems that when trying to authorize towards an App registered in a different home network than you, the authorization code you get back in the OAuth-dance, is invalid. So you'll not be getting an access token, and hence can not get the access token for the external network.
I've looked into an endpoint used by the client-side OAuth flow which is https://www.yammer.com/dialog/oauth?client_id=[:client_id]&redirect_uri=[:redirect_uri]&response_type=token. When I fill in the App info (clientID, redirURI), I get redirected to the login-page, then I get redirected back to the redirURI, and then I have the access token in the URL. Since I'm doing all this authorization from code behind using the OAuth2Client, it seems I'm basically using the same endpoint, but with &response_type=code, to get the Authorization code, and then use that together with client ID and client secret to get the access token.
Is it possible for me to get the access token at all, from outside of the home network the App is registered in?
If anyone has anything to add to this it would be greatly appreciated. I've been stuck quite a while now.
If I left something essential out, please let me know so that I can edit it in. Thanks.
Yammer users are identified by their organisation email address. If I'm from microsoft.com then my home network and external networks are all tied back to this domain. Users in an external network may have one of domains, but when it comes to identity all of that is handled by the home network. In your case you have company.com and possibly a very long list of consultant1.com, consultant2.com domains. These all authenticate back against their respective home networks, and possibly use custom SAML identity providers that you shouldn't need to care about.
By default, apps are tied to their home network which means that users from other networks can't authorize it. The normal way of globalizing an app is to publish it to the public App Directory from within the customer's app settings page. It may be possible to achieve this via a tech support case with Yammer Support at Microsoft. It will probably take some time to get this completed though. It may be best for your customer to open the support case because it's their network which will have the app associated.
Related
At work we have developed an individual customer specific software application that is in use for a long time. We have a new requirement in this same program to implement an option for sending emails directly from the program.
The user is able to add his own email account with the credentials and login through our program. For Microsoft and Gmail accounts OAUTH is implemented and something here is not very clear.
For Gmail-API we have made an OAUTH Client and Consent screen on Google Cloud Console which we need to publish and verify and here is where the problems start. I am not very clear with the whole process of verifying the app.
In the steps for verifying is stated that we should verify a domain for the app, but this software is not hosted anywhere on internet and is not publicly available, it is available to a number of specific users (2000-3000).
Also Google requires a YouTube video of the software to be available publicly, which we are not able to upload because of customer requirements. Also here is required a Data Protection Policy page for the application which we as a developers don't have because we are only developing the software.
Other thing that is not clear to me, how is this type of software rated by Google, internal or public?
Have anyone experience with this or something similar?
Verifying an app for one of the Gmail scopes is a very complicated process. This process depends upon which scope of authorization you are requesting of the users.
In your case you are trying to send an email so you are using the users.messages.send method from the Gmail api. This uses a restricted scope. Which means you will need to go though the full process.
First of it doesn't matter if your application is hosted or not. It also doesn't matter that you give this app to a limited number of users. What matters is the scopes you are using.
You will need to ensure that your domain has been registered via google search console. So this app will need a domain
Once that is done you will be able to host your website, and the privacy policy on that domain.
You will need to create a YouTube video showing your application running, and how authorization is used.
You will also need to submit to a third party security checkup of your application which is not free and will need to be done once a year.
All of this is needed because of your consent screen it doesn't matter if its hosted any where, It also doesn't matter if this is only available to specific number of users.
If all of the users are part of a single google workspace account, that has created your client id and client secrete then you can set the app to internal and you wont need to be verified. This only works for google workspace domain accounts.
I am trying to create a web app for my server which can connect my website forms to Google Sheet. While generating the OAuth client ID and Secret I chose "webserver" and I needed to enter a call-back URI to handle the authorization code returned back from Google as a response.
Well, now I created another client id, but this time I chose Application type as "Desktop" and I didn't need to enter any redirect URI. In my PHP app, I used redirect URI as urn:ietf:wg:oauth:2.0:oob.
However, in both cases, I was able to get Access Token and Refresh Token and my Google Sheet API working smoothly.
So my question why I should choose Application Type as "Webserver" and do an extra step by entering "Redirect URI"? What is the benefit of doing so?
You may check a Quickstart Oauthflow here https://developers.google.com/sheets/api/quickstart/php#step_1_turn_on_the
So my question why I should choose Application Type as "Webserver" and do an extra step by entering "Redirect URI"? What is the benefit of doing so?
Security. Web server client will return the auth to your server. Installed will return it to where ever the request came from. If someone got your client id and secret for a web app they couldn't use it. However if someone got your client id and secret for an installed app they could easily use it to impersonate your developer account.
What is client id and client secret.
Think of the Client id as a login and the secret as its password. This login and password identify your project to Google and they identify the developer of that project as you.
You the developer are responsible for this login and password. If it is stolen then as far as google can see it is your application using it google has no way of knowing other wise. If the login and password for a desktop app is stolen someone could put up an app and as far as anyone would know it would appear to be your app.
You create super awesome email app which gives access to a users gmail account. It becomes very popular and a lot of people know the name. Someone steals your client id and secret creates an app that looks exactly like your super awesome email app. There is no way for anyone to know its not. Because its set up as a desktop app this person could then put it up and start harvesting authorization from your potentiate users without them having any idea. It looks exactly like your app only the responses are going to urn:ietf:wg:oauth:2.0:oob which is the host server of the person who put up this app to mimic yours.
Unless your application is running on a users machine its really not a good idea to use installed credentials. That being said theirs nothing to stop you from doing so it will work.
Note: This is the first time I'm trying to implement a social login API, so thanks for bearing with me and helping me out!
I am developing a web application and I have a login and registration system already developed. Now, I am thinking of adding Facebook and Google+ login - with a backend. I went through their docs and other tutorials and they require to implement considerably a lot of things.
But, since I have a registration system already, I thought of doing something like this:
Have the social login buttons on the login page.
When the user clicks on a social login button and authorizes the app, the user data is returned from Google+, for example.
Now, instead of proceeding with the OAuth procedure like getting the user ID, secret ID and contacting their server from my server for token verification and getting data, is it possible to just use the data returned (after the user authorizes) and do the normal registration with the registration system that I already have?
These are the advantages that I see in doing this:
No need of extra code or database fields like token ID, etc.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
I know the advantages are the same when following the full OAuth2 implementation, but what difference does it make?
Now my questions are:
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
The system proposed by you has certain flaws, especially security related flaw. I would give you to the point answer:
You will send data from client after getting it from google+ or other provider and use your registration process implicitly.
This approach is wrong as I myself as an attacker can send you the data from google+ using my clientid for an app. Will you register or login using the info I am sending? I can pretend to be anyone in your system if you do that.
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
No. (see the reason above).
No. You won't be losing advantage as you already have system in place. Most of the sites have a system in place for normal registration. They give oauth login by leveraging it. Some will say that the password is cumbersome or such, but all famous sites provide login and password including SO.
Now the question comes, how to simplify the oauth system given that you already have a system in place.
I recommend this(I would assume Google as a provider) flow with things starting with dot are what you need to do:
You have a Google login button.
User click on Google Button.
The User is redirected to the Google site.
The user gives you permission.
Google redirects and give you a token.
You can now send info and token to your server. (You need to send only token as backend will get info. Otherwise, a user with valid google+ token for your website can send you any info).
Backend verify token and match that "aud" is equal to your client id. Or it can happen via a library. You will need to give only your client id.
Backend get profile info from token in case of Google+(Name, email) while verifying which you can store as part of your registration process or login process if that email already exists. You can store google id of user also. This is useful as some provider like fb don't always provide email for every account. (For some fb don't give email but for majority of cases it give you the email.)
Backend send back session info or jwt token or any other time bounded process which tells that the user is login.
Your user can login via email also. If he isn't already registered then, then he will need to register. Otherwise, using forget, he can set password or from accounts settings he can set password.
You also need to be careful if the same user is connecting via a different provider, he need to have the same account in your system which you can handle via email.
Kevin,
Authentication is a complex procedure involving lot of measures to ensure security. Hence Web-application/ App developers, delegate this critical piece of work to Identity providers like Google, Microsoft, Facebook etc. These Identity providers are trusted by the app developers and more importantly the consumers trust them too.
Why do app developers provide third party/ social logins? Because, it gives the users of the app some advantages.
They don't have to create new account with the app and remember the new set of credentials. Instead they can use the same credentials they are using with the Identity provider, to gain access to the app. This is huge.
They don't have to trust the app completely, means how the sensitive information like passwords, security questions are handled in the app, as they are not providing any sensitive information directly on the app. Only needed public information is fed to the app from the Identity provider. This is huge too.
No need to worry about the system compromise and leak of sensitive information as all Open ID providers have better security policies in place. This gives consumers a high degree of confidence when using your system through third party logins.
"All the advantages you mentioned will be great for the app developers
at the cost of disadvantages to the consumers of the app."
Lets put the consumer disadvantages on the side and look at the advantages you mentioned:
No need of extra code or database fields like token ID, etc.
You still need code/setup to validate your own tokens. You have to add more logic to verify the external tokens, but the consumers will have the advantage of using the external providers like they are in any other application.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
This is little confusing as users may choose external provider, so they don't have to remember a new password. Also, the account validation process is different if you use external login vs id/password login. If you are willing to provide both, then you already have the system in place, to verify the account for external logins. Then your first advantage is void and you are better of using Open ID spec.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
This approach adds confusion to the flow for consumers. They expect to see a login screen from third party provider for authentication (when they click on google+ or FB), but instead they see your login screen.
Instead of cut short approach, it would be worth to use the complete flow. You might add more logic to handle the token verification with external providers, but, actual complex logic of token validation is delegated to the external providers. This adds no confusion to the end user and they can trust your application easily through social id providers. Even though, users can authenticate through social Id providers, it is always a best practice to have the profile object of that user in your system (without the sensitive information like password).
Since you have your own registration process in place, this may not be a huge advantage. But, please look into the open source implementation of any of the Security Token Service (STS) providers, to see if you can borrow some of the features for validation external providers.
Please let me know if you have any questions.
Thank you,
Soma.
There are a lot of public places that suggest connection to internet via free wifi by login to website or payment. I try to figure out how this work. Do I need server or the web page can run on router? What technology or software do I need? Is anyone can shed light on it?
What you're referring to is Captive Portal
The captive portal technique forces an HTTP client on a network to see
a special web page (usually for authentication purposes) before using
the Internet normally. A captive portal turns a Web browser into an
authentication device. This is done by intercepting most packets,
regardless of address or port, until the user opens a browser and
tries to access the web. At that time the browser is redirected to a
web page which may require authentication and/or payment, or simply
display an acceptable use policy and require the user to agree.
Captive portals are used at many Wi-Fi hotspots, and can be used to
control wired access (e.g. apartment houses, hotel rooms, business
centers, "open" Ethernet jacks) as well.
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.