Duplicate: this must be a duplicate of one of the questions that come up in the following search: Please close it as a duplicate if you agree, and add any answers to one of the other questions.
What is the most RESTful form of authentication? What websites use it? (so I can go look at the documentation).
Looking at some APIs that claim to be REST are really POX
(ex. Remember the Milk - http://www.rememberthemilk.com/services/api/methods/)
I don't know if this is the 'most RESTful' form, but Amazon's S3 uses an authentication method which is documented here. Each request is signed, so there is no session to track on the backend, but you can still securely verify what user issued the request.
The most RESTful authentication method is probably HTTP Basic. Because it has some significant weaknesses (replay attacks), most APIs tend to shy away from it.
Open Sourcery has a well-thought-out article on RESTful authentication. Sounds like there are no awesome solutions right now beyond simple user/pass auth over SSL and then keeping auth info in subsequent request headers.
Related
I am a beginner in the world of the OAuth2.0 and OpenID Protocols. I would like to implement a custom server - provider for multiple applications. So, to use it for Single Sign-On (SSO). I would like to work with python. Till now I have found four packages, for an OAuth2.0 and an OpenID Connect server implementation, in Python: pyoidc, django-oidc-provider, Django OAuth Toolkit (DOT) by OAuthlib and Authlib. I tried to read and understand pyoidc, but it was not so helpful and easy, basic things were missing. I have tried django-oidc-provider and I was really satisfied, and the whole implementation was really easy. So, after those trials, I am left with Django OAuth Toolkit (by OAuthlib) and Authlib. Has anyone tried them? Are these packages the same? Is Authlib an updated version of the OAuthlib library? The only information I know till now, is that Flask-OAuthlib is deprecated, and Authlib is was its new version.
*Every answer or advice or personal experience would be really helpful and always appreciated!
Thank you again for your help.
After some research, I concluded to work generally with JWTs. As before, I would like to work with a GraphQL API, so I am searching for solutions about JWT authentication on it. I maybe use Passport.js (passport-jwt) or something else for Python. All the libraries mentioned above possibly will be not used.
I will just redirect the user to my main application, authenticate them with JWT, and then return the JWT back to the application. In the future and after deployment, I might also implement an OAuth2.0 provider for my website. Although those packages did not really help me, I would recommend Django OAuth Toolkit (DOT) and django-oidc-provider to others. But, also I learned that django-oidc-provider only supports the implementation of a small and simple OAuth2.0 provider. Django OAuth Toolkit comes with lots of options for implementing an advanced OAuth2.0 Authentication Server (AS), including Authorization Code flow with PKCE (Proof Key with Code Exchange), which is the most secure flow. It is also scalable and has great documentation with lots of customizations if you want.
*I sent an email to the support of Authlib, and of course no one has answered to me after a week.
I'm trying to purge several URLs via php of Akamai servers. So far I've been using the CCU Rest Api which simply sends a HTTP-Request with the urls and options encoded in json. I've heard that the support of this API will end soon so I wanted to use a different API to do it.
I wanted to use this one
Since the documentation is really unstructered and does not tell anything how to send the credentials to the server. I already found their GitHub repositry but I didn't understand anything because I'm pretty new to PHP.
Can someone please explain me how to send only the Purge Request? Validation and checking the results is a piece of cake, the Request is the point where I'm struggeling.
Thanks a lot
You can use the newer OPEN API, I've written a blog post telling you how to get started
https://community.akamai.com/community/developer/blog/2015/08/20/getting-started-with-the-v2-open-ccu-api
The older API is much less secure, and the newer method will allow, very soon, for 5 second purges.
Let me know if you have any more questions,
Thanks,
Kirsten
My team and me are currently working on quite a large project. We are working on an online game, which will be accessible (for the moment), in two ways:
-Via a web browser, an application full JavaScript(client-side), full Ajax (basically meaning that the UI will be managed in JS client side).
-Via an iPhone application (the UI will be managed by the application itself).
Between the two different applications, the core logic remains the same, so I believe (I could be wrong), that the best solution would be to create a web service (if possible using standards such as RESTful or Rest) capable of perming all necessary operations.
Following this logic, I have encountered a problem: the authentication and identity management of the user. This poses problem as the applications users need to be authenticated to preform certain operations.
I’ve looked into WS-security, but this obviously requires passwords to be stored, unencrypted on the server, which is not acceptable!
I then looked into Oauth, but at first glance this seemed like a lot of work to set up and not particularly suited to my needs (the way that applications have to be accepted does not please me since it will be my application and my application only using the web service, not any external application).
I’ve read and heard about a lot of other ways to do what I want, but to be honest, I’m a little confused and I don’t know what information is reliable and what isn’t.
I would like to note that I’m using symfony2 for the backend and jquery for the client side JavaScript.
Furthermore, I would like a detailed, step-by-step response, because I really am confused with all that I have read and heard.
Thank you for your time, and I hope someone can help me as it’s quite urgent.
Good evening
I'm not entirely sure if this answers your request, but since the UI will always be handled on the client side, I think you could use stateless HTTP authentication:
This is the firewall in security.yml:
security:
firewalls:
api:
pattern: ^/api/ # or whatever path you want
http_basic: ~
stateless: true
And then the idea basically is that on the server, you use your normal user providers, encoders and whatnot to achieve maximal security, and on the client, you send the HTTP authentication headers, for example, in jQuery:
$.ajax("...", {
username: "Foo",
password: "bar"
});
Please note that since the authentication is stateless (no cookie is ever created), the headers have to be sent with every request, but, I figure, since the application is almost entirely client-side, this isn't a problem.
You can also check the Symfony2 security manual for further information on how to setup HTTP authentication. Also be sure to force HTTPS access in your ACL, so the requests containing the credentials are secured (requires_channel: https in your ACL definitions).
I'd like to use the evercookie javascript library to receive the users cookie and make the spring security rememberme-service use it.
I read a bit about implementing a custom remember-me service, but I think I just need to discover the cookie on the client-side using the evercookie library. I've got zero knowledge about cookie handling, so any help how to implement the evercookie library so that a cookie will be set and discovered through the library would be appreciated.
evercookie: samy.pl
In my opinion evercookie isn't good choice. It is generating tremendous number of http requests. It has killed my browser. Your users will be fourious about it.
See http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/Cookie.html
I see APIs such as PayPal, etc. offering to call their services using NVP or SOAP/WSDL. When using a .NET environment (3.5) using traditional web services (no WCF) which is better and why? I know WSDL lets you drop in the API URL and it generates the wrappers for you. So then why do companies even offer NVP?
There seems to be never-ending confusion in this industry about the different types of web services.
SOAP is a messaging protocol. It has as much in common with REST as an apple has with a lawn tractor. Some of the things you want in a messaging protocol are:
Headers and other non-content "attributes."
Addressing - routing of a message to different servers/recipients based on the headers;
Guaranteed delivery via queuing and other methods;
Encryption, signing, and other security features;
Transactions and orchestrations;
Accurate representation of complex structured data in a single message;
...and so on. This is not an exhaustive list. What WSDL adds to SOAP, primarily, is:
Discoverability via a contract, a form of machine-readable "documentation" that tells consumers exactly what is required in order to send a message and allows proxies to be auto-generated;
Strict, automated schema validation of messages, the same way XSD works for XML.
REST is not a messaging protocol. REST is a system of resources and actions. It is a solid choice for many architectures for several important reasons as outlined by other answers. It also has little to no relevance to "NVP" services like PayPal and flickr.
PayPal's NVP API is not REST. It is an alternative, RPC-like messaging protocol over HTTP POST for clients that don't support or have difficulty supporting SOAP. This isn't my opinion, it's a statement of fact. One of the fields in the NVP is actually METHOD. This is clearly RPC verbiage. Take a look at their API for UpdateRecurringPaymentsProfile and try to tell me that this makes a lick of sense to describe as a "resource". It's not a resource, it's an operation.
In the case of PayPal specifically, the "NVP" (HTTP POST) API is inferior to the SOAP API in almost every way. It is there for consumers who can't use SOAP. If you can use it, you definitely should.
And I'm not necessarily bashing PayPal for this, either. I know a lot of folks have bashed them for not putting together a "proper" RESTful API but that is not what I am getting at. Not every service in the world can be accurately described with REST. PayPal isn't really a resource-based system, it's a transactional system, so I can forgive their architects and developers for not having a perfectly elegant REST architecture. It's debatable perhaps, but it's not black-and-white. It's fine; I'll just use the SOAP system if I need to.
Compare this to, say, the Twitter API. This is a true REST service. Every "operation" you can perform on this API is accurately described as either the retrieval or submission of a particular kind of resource. A resource is a tweet, a status, a user. In this case it literally makes no sense to use a complex SOAP API because you're not really sending messages, you're not performing transactions, you're just asking for specific things, and these things can be described with a single URL. The only difference is that instead of getting an HTML web page back, you're getting some XML or JSON data; the way you request it is exactly the same.
A REST Web Service usually (always?) uses HTTP GET for the retrieval of some resource. And Twitter does exactly this. GET still uses "Name-Value Pairs" - that's the query string, ?q=twitterapi&show_user=true. Those bits after the ? are name-value pairs. And here's a great example of why you would want to use REST over SOAP; you can hook this up to an RSS feed and get streaming updates. I can turn it into a Live Bookmark in Firefox. Or I can download it in JSON format and bind it to something like a jqGrid. The interesting thing is not that the request uses "Name-Value Pairs"; the interesting thing is that it's a simple URL and can be consumed by anything that knows how to request a web page.
So to try and summarize all of what I've said, think of it this way:
Use a REST API (if available) when you want to expose data, or consume or publish it, as a permanent resource.
Use a SOAP API when the system is transactional in nature and/or when you need the advanced features that a complex messaging protocol can offer, such as RM and addressing.
Use an RPC API (which includes just about any API that's modeled entirely around HTTP POST) when there is no SOAP API or when you are unable to use the SOAP API.
Hope that clears up some of the confusion.
I assume that by Name Value Pairs, you mean REST services.
The benefits to REST are primarily ease of development, simplicity and elegance, and lower overhead (which is very important if you are sending and receiving a lot of small messages).
Here are some of the advantages of REST:
REST is more lightweight
Human readable results
Everything is a URI addressable resource
REST services are more easily cached
REST is easier to build (no toolkits are required)
REST is easier to call (HTTP - GET, POST, PUT, DELETE)
NVP is HTTP POST
name=fred
amount=100
code=403
etc
This is the default format from any HTML browser so it's simple to implement for sending data to a web service
I don't think it's a good format for receiving data from web service? JSON or XML would be more suitable
No everyone uses VisualStudio, or has access to automatic wrapper generators, or wants to use such a beast
Many web mashups are coded in Javascript, so using HTTP POST to send data is the simplest way. The return result is a standard HTML response code (200, 403, 500, etc) and/or some JSON
Many service providers offer multiple API's to cater for all customers