I've been researching PASTEBIN type API's that would enable storage of code snippets for a project I'm working on. The problem is that most if the API's I've found do not support edit/update of existing pastes.
I found that the Snipt.org API does support snippet updates. However, authentication for the snipt.org API is done using your Twitter account. The snipt.org API docs (https://code.google.com/p/snipt-org/wiki/REST_API_Docs?tm=6#Authorization) suggest using a GET '/auth' call (providing a Twitter uname/password in the URL) to obtain an API token to access the API. Is it just me or does this seem like a good way to compromise your Twitter credentials?
I have used other sites that authenticate via Twitter, but I get authenticated on the Twitter site first which in turn sends a token to the authorized app.
Well, obviously this API has some serious flaws.
But if you use https, the URLs of GET requests will get encrypted along the way. (But still get logged in the cache of your browser. do clear it.)
So if you really like snipt, you could use a new twitter account created simply for the purpose of authenticating to snipt.
It won't feel particularly good. And I have some serious doubts about the rest of their security code based on this part of the API. But I do not see how exactly your credentials could be stolen using this part of it by others than the snipt maintainers who already have access to your snipts. So if you protect only snipts with the credentials, and no tweets, you should be alright.
Related
I'm having trouble understanding how ASP.NET Core authentication works.
I want to implement JWT access token authentication with refresh tokens. To my knowledge, this is the industry standard for authenticating a client (Mobile app, SPA Web application). For security purposes, I'd prefer to not implement my own authorization logic including JWT generation and refresh token handling. Since ASP.Net does not natively support this, Naturally my choice would be to use IdentityServer4, a large open source library for handling this kind of stuff.
However IdentityServer4 is heavily based on OAuth, and I'm not sure how that works with SPA applications and mobile apps (clients I trust). It requires the client to redirect to some arbitrary webpage to enter their credentials and then redirect back to the app. Gross. I've never seen a major app like Snapchat, Instagram, etc. have this kind of authentication flow where you are directed to some webpage/browser during the login flow. Luckily IdentityServer4 has a little feature to handle username/password authentication for my trusted clients (http://docs.identityserver.io/en/latest/quickstarts/2_resource_owner_passwords.html)
Great, that seems to suit my needs. But... Now I want to add Facebook Authentication. IdentityServer4 allows for External Authentication, however it is still cookie based (to my knowledge). Which requires the Android/iOS/SPA app to redirect to a webpage and then redirect back to the app. Again, this isn't ideal from a user perspective. Facebook provides native mobile SDKs to handle this type of authentication which returns an access token so there is no need to redirect to web pages using cookies.
Now lets say my iOS app uses the Facebook SDK to grab an access token for the user and sends it to the backend. The backend validates the token against the Facebook SDK, and subsequently registers a local user in it's own database.
Now when that same iOS user tries to login to the app, the app will generate a facebook access token for that user from the SDK and send it to the backend. However I'm not sure how to utilize IdentityServer4 to generate a JWT for the user since I need that users' username and password. This is where I'm stuck. I seem to be fighting against the library which makes me believe I am severely misunderstanding something.
TLDR; IdentityServer4 seems to be heavily based on cookies which doesn't really fit nicely into mobile apps/SPA webpages when you are redirected back and forth from authentication webpages. Am I using the wrong tool for the job? What are some alternative solutions?
As a note on big social apps: I think it comes down to who keeps the passwords. Facebook, Instagram, Snapchat, Google act as identity providers to third parties. They themselves require user to register and specify the password which they keep. Therefore they can use any customized approach for handling validation with those passwords. However, if any of them offerred a posibiltty to log-in with the other I.e Instagram were allowing to sign-in with Amazon credentials, then they would need to follow through a standard way like OAuth and redirect to the third party for log-in. Last time I checked Instagram, Facebook and Snapchat only offer to register and no option to sign in with 3rd parties which explains why the don't need redirects.
Now if we establish that a redirect is a necessary evil, then the means to carry over the data accross aren't that numerous. I.e. we either would need to pass data via a query string or use cookies. Am I missing any others?
Both have limitations but since cookies are persisted and browser carries them automatically with each request, they do seem like a better option for the job, especially if multiple redirects are required for an external IdP to track the state of authentication request. The same reason is mentioned here:
http://docs.identityserver.io/en/latest/topics/signin_external_providers.html
It's absolutely the right tool for the job if you want what OpenID Connect and OAuth2 give you. It sounds like you may need convincing though and it may be that your use case doesn't need the full breadth of functionality offered.
If you have multiple client applications and APIs in play then I think using OpenID Connect and IdentityServer4 the right choice at this point in time.
Regarding native apps, you used to word "gross" to describe using the user's default browser to perform the sign in process and it's understandable why you might think that at first but it's not as bad of a UX as you'd think and has plenty of advantages:
The client application is completely decoupled from how authentication is actually done be that federation, social sign in (Facebook in your case), multi-factor, retina scan etc. Your identity server deals with all that complexity and is a single point of management (and failure - so make it highly available!)
Single sign on is possible - if they're already signed into your IDP then they can go straight in (although you have full control of the flow - want them to consent or confirm the sign in request every time - you can do that)
If the user has a password manager set up in their browser then that'll work too
Both iOS and Android offer APIs for doing this stuff and the work well. If you skin your native and web UIs to look similar the flow from a user's PoV is not jarring at all.
You can still use refresh tokens (ultimately secured by the platform) so you don't actually have to do the interactive flow very often anyway.
Some additional reading below. Quite a lot of thinking has gone into this from the industry so it's definitely worth digesting the current best practice.
https://developers.googleblog.com/2016/08/modernizing-oauth-interactions-in-native-apps.html
IETF current best practice: https://www.rfc-editor.org/rfc/rfc8252
Don't make Scott hate you ;) : https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications
For client side SPA browser apps OIDC provides the implicit grant type and uses a silent refresh and IDP session monitoring mechanism to maintain the session. Check out the oidc-client-js library which implements this approach.
I've an ETL tool that is capable of making REST API calls against the Yammer network and retrieving data for analysis. Currently, how I make Yammer REST API calls is through an App that I've created. I then generated the authentication token and then used this token in the REST API calls to get at the data.
What I'd really like to do now is to provide an app that allows me to call the REST API (using the same ETL tool) without the person installing the app to have to go through the rigmarole of generating the auth token.
I suppose one approach could be to use some JavaScript that displayed the token to the user so that they could then pass it on to us... Do you folks have any other suggestions as to how I might do this?
There isn't a recommended way to skip the OAuth authorization, but you can automate a lot of it away. I created a Python script that uses the YamPy library to acquire a token. It even fires up the browser to the correct URL for authorization. You should be able to do something similar with other languages.
Calling the impersonation endpoint is another possibility. This will get you an OAuth token for another user so you'd need to have an app is just for producing OAuth tokens. It's probably a bit trickier to build right and secure than my script. Impersonation was designed for a specific category of app which means I don't recommend it by default. Even when it is a workable option it hides the authorization from end users which can potentially be a security issue, if say you app is compromised and handing out OAuth tokens. At least if the Yammer screen is in the way it's a bit more visible to the user what is happening.
I am building an API that is going to be used by a partner's website. The website will be in the same domain (api.example.com and www.example.com). In the future we might have a mobile app that will consume this API.
I would not like to have someone using my api for their own website/app. So I would like to have a way to validate my website to my API.
I've searched in SO and found out that I would have to set a Cookie in my website so I send it every ajax request. Fair enough, but how would I generate this cookie? If I call a method in my API, I would have to validate it's origin, so it wouldn't solve.
I could set an encryption key on both sides and encrypt some information with a salt and send to the api to check the information.
I am not a security expert, but it seems it would solve my issue. Is this correct?
When a user logs into my website, would it be safe to change this validation with the user's login token?
thanks!
What your describing is called a CSRF (Cross Site Forgery Request).
To prevent someone from accessing your API's from outside your request, your website should store a token within the session, pass this token for every API request, then the API should validate the token.
There is a ton of good articles on the subject, including many specific examples.
Here is one of them preventing-cross-site-request-forgeries
I need to get an access token from differente providers from the client side.
The idea is that I need the user to authenticate with these providers from javascript, and then retrieve an access token to be used to authenticate against another web service...
So far now, we managed to do it on twitter using twitter-anywhere, in facebook using the javascript SDK and in google using it's api-javascript-client
I was wondering if there's a similar solution for yahoo, linked and github. Or even better, a more general solution that could handle different providers...
Surely, there is one for Linkedin.
http://developer.linkedin.com/javascript
http://developer.linkedin.com/documents/javascript-api-reference-0
Not sure if this was around when the question was asked. For github, the comment by #Ivan Zuzak would suffice.
This link has a workaround with a little server support - http://blog.vjeux.com/2012/javascript/github-oauth-login-browser-side.html
I am trying to develop a non-web application (mobile, non-mobile) for consuming information from Foursquare.
I would like to have the user authenticated by entering a valid username and password and accessing his account using this authentication.
Is this possible? From what I've read, it seems the only way to access Foursquare is by using OAuth, which is not what I had in mind.
Any thoughts?
Thanks!
RP
OAuth isn't a protocol that works only with webbrowsers. However, many OAuth services provide a web-only authorization endpoint. Once the authorization part is done, you can use OAuth from any application, web, desktop or mobile (and embedded systems).
There are many ways to handle this browser requirement, but these two are very common:
Simply embed a webbrowser in your application that shows the user the authorization page, let him log in, and finish the OAuth sequence. Once that's done, you have the keys and don't need the browser anymore.
Use an external browser. This is definitely the recommended approach, since it's more secure and users will probably like it a little bit more. The idea is that you simply open the authorization URL using the user's webbrowser, and set a redirect URL that points back at the app. This is normally done using a myapp://auth URL, which will simply send the data to the application again.
I believe OAuth is your only option if you plan on using the Foursquare api. You can read about Foursquare's Authorization here https://developer.foursquare.com/overview/auth