Is it possible to use Smartsheet's API to sign into Smartsheet on the Web. I am thinking of creating a form-based auth that uses the API to login. Has anyone done something like this? or is this even possible with the tokens that can be produced by the API. I am aiming for a web based single sign on without using SAML.
I'm not totally clear on what you are asking, so I'll address each question individually in hopes that it addresses your overall question:
Is it possible to use Smartsheet's API to sign into Smartsheet on the Web?
No, you cannot create a web session using the api. For 3rd party apps, that would defeat the purpose of using OAuth2 since the whole goal with OAuth is to grant limited access to protected resources. For user-generated access tokens, it could be feasible, since those tokens have unrestricted access, but the API does not currently support that.
I am thinking of creating a form-based auth that uses the API to login. Has anyone done something like this?
I assume you mean you will create a form to collect a user's Smartsheet credentials and use those to have an SSO experience into Smartsheet? This is technically possible, but I'd strongly discourage against it. To create an SSO experience, you'd need to retain the password in a way that allows you to POST it on behalf of the user. This means you'd store it in a 2-way encrypted state (at best), which is definitely not best practice. Again, I'd highly recommend NOT doing this.
I am aiming for a web based single sign on without using SAML.
If you want an SSO experience into Smartsheet, you can either use SAML or Google (not truly SSO, but pretty close). There isn't an API-based approach currently.
Side note, if you want to go the other way, meaning you have a website and you want to use Smartsheet (or any OAuth2-based API for that matter) as the identity provider, you could use the 3rd Party OAuth2 flow. See the docs here. You could then add a "Login with Smartsheet" button to initiate that flow, much like we see everywhere on the web with "Login with Google" or "Login with Facebook".
Related
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'm building a single-page web application, fully based on RESTful API. I've seen several topics in that matter, but some things remain unclear for me.
I will need users to log in. Here are some of my ideas:
I can send e-mail and password to API and use basic auth. I'm not sure where should I keep password, should it be encrypted and if so: how?
Can I use built-in session system instead? Is it wrong to use cookies directly in the RESTful API? Why is it so popular to send credentials/keys to API itself instead of using cookies?
I thought about having one API key per user, return it in login action and keep it in localStorage. I guess it's not the greatest idea to have just one key per user?
Then, I came up with idea to have separate keys table and add random keys each time somebody logs in. On logout, the key would go away and no longer be valid. This is more secure than previous idea.
How is it solved in simple projects? I'd like to make it simple but not ridiculously inserure.
Please help.
The commonly approach is to use the header Authorization in REST. The state of the application must be on the client side with REST and shouldn'a be tied to a particularly client kind (browser with cookies)
I think that this link could be helpful:
Implementing authentication with tokens for RESTful applications : https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
There is also à great question to à similar question here : https://softwareengineering.stackexchange.com/questions/141019/should-cookies-be-used-in-a-restful-api
Hope it helps,
Thierry
Background: I am trying to create an SMS API service. The developers have a Dev ID, and an API secret key assigned to their developer account. The developers will be creating apps which will issue calls to my API. But the application issuing the call must be verified first.
Issue: The main issue i have is with authentication. I read up on OAuth and pretty much uderstood it. I read through this presentation (Slide 71-82). All OAuth articles talk about the OAuth 'dance' or the 'love triangle'. My problem seems to be, that i dont see a proper triangle in my case. Or, a better way to put it would be, the triangle doesn't seem to be complete.
What i mean by that is, in the case of lets say, LinkedIn, trying to make some app which helps users associate their LinkedIn acc with twitter, OAuth makes complete sense. Because LinkedIn needs to get resources from twitter ON THE USERS BEHALF (Cuz the user HAS A TWITTER ACCOUNT). In my case, only the consumer has a developer account registered with my service. The end-user doesn't have any credentials for the consumer to ask on behalf of. So how can i implement Oauth? So what will the consumer ask the provider? Will it only state that "watch out, here i come?". Cuz that seems pretty pointless unless its asking for a request token in exchange for an access token. But in this case since the end user doesnt even have an account, the steps seem useless.
So, i cant figure out how to go about this authentication issue. Ive tried thinking about using php sessions so it can help me associate a token with the particular client who is using the API. But the REST/OAUTH purists seem to disagree on the usage of sessions in authentication. They claim that OAuth is a standard which has proven itself and that is what I should use instead of coming up with my own obscure schemes.
From your description it seem that you're in a two party scenario only (developers write code which accesses your API on their own behalf, not on behalf of an end-user), so that means indeed that doing the full 3-legged oAuth scenario isn't needed.
You could use pretty much any authentication scheme and that would work (API Keys, other oAuth grant types [see below] or even ID/Secret combinations. In the oAuth world:
Look at the other oAuth 2.0 Grant types: especially resource owner PW grants - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.3. It's slightly better than username-password because the PW isn't passed across the channel all the time (it passes once though) and it assumes the developer writing the code is the owner of the credentials.
Look at oAuth v1.0: this different in various ways to v2.0 but one feature it does have which some people like is the way tokens are used - which is rather than being passed across the wire they are used to generate a hash in the client and then the hash is verified on the server side. It's more expensive and complex than checking a key but it's less prone to attack.
In the non-oAuth world, if it's primarily a server resource used by developers directly, an ID/Secret or API-Key pattern is probably more than sufficient and it's much easier to implement for your developers.
Re: oAuth - if you're doing any type of user auth then definitely stick with the standard - the stuff is complex and having libraries out there really helps. If it's developer-api you likely don't need to go that far.
If you want the API to be secure in an ideal world anything which requires the security token to pass across the gaps should be secured using SSL, especially if that client code could be running on a mobile device or laptop which might communicate over wireless. If this isn't the case, someone could jump in an copy a token from one of the devs.
The only one of the protocols above that avoids this is the oAuth 1.0 variation since the secret never leaves the client but is used to hash instead. But it's complex. Last one to look at is the Amazon AWS pattern which does hashing similar to oAuth 1.0 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html and people emulate quite a bit.
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/
Which are the steps must I follow to implement a token authentication in my web page?
Any summary or links will be appreciated.
I want to implement similar to Facebook or Google, first time client loggin and receive token and then use it in next actions.
I read also about OAuth but I don't want to give access to my application from 3rd party.
Thanks for the long response and it seems clear to me I need to read more about this.
What I want is to know the "steps" to implement a basic web application that uses token authentication. That is user logging once and then can make some actions: add content, edit, etc.
I know what I'm saying is similar to a session, where server adds a SESSION_ID on the HTML header and later request are identified and associated with that session. I read sessions way isn't good to scale so I want to implement a similar system like gmail or facebook before they go to OAuth. Probably I'm talking about something similar to oauth (i don't read in much depth) but witj two-legged instead three-legged.
You should think about your requirements, pick an appropriate protocol and some decent piece of software that implements it.
It's really hard to say more without more details:
are you talking about authentication for one or for multiple web applications? do you need single sign on between different web applications?
should all user data be stored on your server or should user be able to login e.g. with the google account?
should the token contain informations about the user?
on what platform are your applications developed?
what authentication method should be used?
do you want to realize a portal?
There is a really wide range of protocols and tools which might or might not fit to your requirements:
http://en.wikipedia.org/wiki/Category:Authentication_methods
http://en.wikipedia.org/wiki/Category:Identity_management_systems
I personally like CAS ( http://www.jasig.org/cas) for token-base SSO between multiple web applications. It's Java based but also has some support for PHP and .Net.
OpenID is fine, if you want to allow users to login with their Google, Yahoo, whatever account (configurable...) and don't want to store user information by yourself.
Kerberos/SPNEGO is the way to go if you want to haven integrated windows-sso for your corporate intranet applications.
For university applications SAML/Shibboleth probably is best. Outside universities it's somewhat less popular, probably cause it's a fairly complex protocol.
Oh and I almost forget: Most of the web frameworks/standards have there own version of plain-old "form based authentication". Where a user goes to a login form enters its username and password. Both are with or without SSL transported to the web/application server. The server validates it against some kind of database and gives a cookie to the user, which is transmitted and validated every time the user sends a request. But beside all this shiny protocols this seems to be pretty boring :-)
And before doing anything with web authentication, you might think for a moment about web security in general ( http://journal.paul.querna.org/articles/2010/04/11/internet-security-is-a-failure/ http://www.eff.org/files/DefconSSLiverse.pdf) and what you can do to not make it even worse on your site ( http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf).
see your point.
On the protocol level a very simplistic token approach is HTTP Basic Authentication. But this often doesn't fit, as there is no logout function etc.
A custom, simple cookie based approach can for example look like this:
The server generates some kind of secret (a value that is hard to guess)
When a user tries to access a protected resource, he is redirected to a login form
after successful authentication he gets a cookie. This cookie contains three values: username, timestamp and a hash of {username server-secret timestamp}.
with every user request the server recalculates the hash values and compares it to the value which the client sends in its cookie
(needs more consideration of: httponly and secure flag, transport layer security, replay attacks etc)
Amazon S3 stores its authentication token in an HTTP Header and uses HMAC for calculating it. It's described here: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?S3_Authentication.html (Not necessarily recommended for using with a browser based web application)
If there is a book about REST anywhere near you, you may look if it has a chapter about authentication. Probably things are much nicer explained there than here :-)
There are some frameworks which are capable of doing this kind of authentication. For security reasons it would make sense to check them first before implementing your own stuff.