What opensource Java library can be used to parse/decrypt JWT token in JWE JSON serialization format as below
I was looking at nimbus-jose (https://connect2id.com/products/nimbus-jose-jwt/) but I cannot find any releavnt example. I want to use some open source library which will require little coding and will support different encryption algorithms out-of-the-box.
Unfortunately the JSON Serialization modes are often missing from implementations.
This is mainly due to the fact that this mode is rarely used as not URL safe.
It is possible to convert JWE from that mode to the compact mode, but only if there is no aad and header members which is not the case here.
I see only few possibilities to solve your problem:
Ask developers to implement that feature (can be long).
Develop your own implementation (not so easy).
Find an implementation in another language that supports that format (e.g. in PHP).
Related
I was wondering what the general opinion was about using different serialization methods for REST APIs. JSON and XML are the most popular but I was wondering if serialization in Flatbuffers might be a possible alternative.
Deserialization on the server side is technically cheaper than JSON (the big win is "zero-copy" reads and fast serialization responses on larger servers). On the client browser FB serialization would be slower than JSON (JSON serial/deserial is implemented natively) but I think that's minor given that the datasets are extremely small the user wouldn't notice a difference anyways.
I imagine REST purists would say this is taboo. The downsides would be:
Tooling for reading FB in REST isn't quite there
Client-side performance with larger datasets isn't as performant
MIME type sent would be application/octet since FB doesn't have its own MIME yet
This thought came from the fact that I'm using FB in gRPC and now have to accept requests via browser. Transforming from REST adds an extra serialization step (if I took a similar approach to using gRPC-Web).
There is nothing about REST that specifically dictates or suggest any mimetype. REST predates JSON, so purists definitely should not call this taboo =)
I am trying to replace HSM(s) with my software-only application and integrate with PKCS11. The problem I have with that is all of PKCS api functions deal with slots and tokens which are not a part of my software application. Are there examples out there that I can look up to see how a software application can be used to imitate an HSM and integrate with PKCS ?
When you are dealing with HSM's you have to deal with slots and tokens. You have to modify your software slightly to accommodate this.
There are 2 ways you can use the PKCS#11, PKCS#11 Wrapper or PKCS#11 Provider. The Wrapper is the api that calls the native functions of the HSM library (.dll or .so) directly. The Provider uses the Wrapper under the hood, but gives you the convenience of using it with Java KeyStore api.
Considering your case, the Wrapper might not be fit for you, because it involves writing new classes to integrate with the HSM. You could use the provider.
Java has very good documentation of the PKCS11 Provider here. There is also a very good third-party library called IAIK, here is their provider documentation. Even though you use the Provider in your software application, trivial code changes are inevitable.
Where ever you have used the KeyStore api, you may have to make changes there. And initially, when your software loads, you have to load a configuration file for the PKCS11 provider that tells which slot number and the token to connect to.
IAIK has very good examples too, and their provider library is only free for development purposes.
We are going to set up a solution where the iPhone is requesting data from the server. We have the option to decide what kind of solution to put in place and we are not sure about which way to go.
Regarding SOAP I think I have the answer, there are no really stable solution for doing this (I know there are solutions, but I want something stable).
How about REST?
Or is it better to just create our own XML? It's not going to be so complicated reguest/respons-flow.
Thanks in advance!
I've created an open source application for iPhone OS 3.0 that shows how to use REST & SOAP services in iPhone application, using XML (using 8 different iPhone libraries), SOAP, JSON (using SBJSON and TouchJSON), YAML, Protocol Buffers (Google serialization format) and even CSV from a PHP sample app (included in the project).
http://github.com/akosma/iPhoneWebServicesClient
The project is modular enough to support many other formats and libraries in the future.
The following presentation in SlideShare shows my findings in terms of performance, ease of implementation and payload characteristics:
http://www.slideshare.net/akosma/web-services-3439269
Basically I've found, in my tests, that Binary Plists + REST + JSON and XML + the TBXML library are the "best" options (meaning: ease of implementation + speed of deserialization + lowest payload size).
In the Github project there's a "results" folder, with an Excel sheet summarizing the findings (and with all the raw data, too). You can launch the tests yourself, too, in 3G or wifi, and then have the results mailed to yourself for comparison and study.
Hope it helps!
REST is the way to go. There are SOAP solutions, but given that all people end up doing with SOAP can be done with RESTful services anyway, there's simply no need for the overhead (SOAP calls wrap XML for data inside of an XML envelope which must also be parsed).
The thing that makes REST as an approach great is that it makes full use of the HTTP protocol, not just for fetching data but also posting (creating) or deleting things too. HTTP has standard messages defined for problems with all those things, and a decent authentication model to boot.
Since REST is just HTTP calls, you can choose what method of data transfer best meets your needs. You could send/receive XML if you like, though JSON is easier to parse and is smaller to send. Plists are another popular format since you can send richer datatypes across and it's slightly more structured than JSON, although from the server side you generally have to find libraries to create it.
Many people use JSON but beware that it's very finicky about parsing - mess up a character at the start of a line, or accidentally get strings in there without escaping "'" characters and there can be issues.
XML Property-lists (plist) are also a common way to serialize data in Cocoa. It is also trivial to generate from other languages and some good libraries exist out there.
You are not saying how complex your data structures are and if you actually need state handling.
If you want to keep your network traffic to a minimum, while still keeping some of the structured features of XML, you might have a look at JSON. It is a very light weight data encapsulation framework.
There are some implementations available for iPhone, for instance TouchJSON
Claus
I would go with simple HTTP. NSURLConnection in the Cocoa libraries make this pretty simple. Google Toolbox for Mac also has several classes to help parsing URL-encoded data.
I think it's obvious that REST is the new king of servers communication, you should definitely use REST, the questions should be what REST methodology you should use and what coding language, in my post I present few very simple implementations for REST servers in C#, PHP, Java and node.js.
I'm writing a simple application that communicates with an external server.
The server currently supports yaml, xml and json.
Which encoding is fastest on IPhone?
Which has better support?
What libraries do you suggest?
I worked on a project that connected Motorola handsets running J2ME with a speech server in the network. We found that total bandwidth was worth optimizing (this was on a 2.5G network in 2004). So I'd suggest you measure how many bytes each serialization format takes and go with the smaller one (which will be JSON or YAML). You might even consider using a binary protocol like Hessian or Google's Protocol Buffers.
We also discovered that minimizing the number of messages decreased latency, so be on the lookout for ways to send data to the iPhone in fewer, larger chunks, use an HTTP cache on your phone, use HTTP entity tags and If-Modified headers, and so on. Since you're using REST, you're well positioned to leverage all these nice features of HTTP.
Of course this can all very easily be premature optimization, so code it up the easiest way possible and measure first.
I've created an open source application for iPhone OS 3.0 that shows how to use REST & SOAP services in iPhone application, using XML (using 8 different iPhone libraries), SOAP, JSON (using SBJSON and TouchJSON), YAML, Protocol Buffers (Google serialization format) and even CSV from a PHP sample app (included in the project).
http://github.com/akosma/iPhoneWebServicesClient
The project is modular enough to support many other formats and libraries in the future.
The following presentation in SlideShare shows my findings in terms of performance, ease of implementation and payload characteristics:
http://www.slideshare.net/akosma/web-services-3439269
Basically I've found, in my tests, that Binary Plists + REST + JSON and XML + the TBXML library are the "best" options (meaning: ease of implementation + speed of deserialization + lowest payload size).
In the Github project there's a "results" folder, with an Excel sheet summarizing the findings (and with all the raw data, too). You can launch the tests yourself, too, in 3G or wifi, and then have the results mailed to yourself for comparison and study.
Hope it helps!
Using json-framework, making your classes interoperate with JSON is ridiculously easy.
Well, if you want to use XML, use a plist, since its supported natively on the iphone.
JSON is not, but there are some good c libs available. I support JSON and XML in my app.
Same with XML - there's a bunch - just search around.
It also depends what media-types your server supports - btw, REST isn't really a protocol.
I have some benchmarks comparing the performance and payload sizes of the different serializers available here:
http://www.servicestack.net/benchmarks/NorthwindDatabaseRowsSerialization.1000000-times.2010-02-06.html
Basically, if you're developing with .NET web services than you are going to be making a compromise on payload size vs performance, unless you go with another serializer.
Marc's protobuf-net shows the smallest and fastest implementation:
6.72x faster and 4.68x times smaller than MS's fastest Xml Serializer; and
10.18x faster and 2.24x smaller than MS's JSON DataContract Serializer;
Although being a binary protocol, it may be harder to debug.
If your developing with MonoTouch (i.e. C#/Mono for the iPhone) and want to use a text-based format, than you may be interested in my Javascript-like type serializer that has been optimized for size and speed, it also shows modest gains over the available XML and JSON options, namely:
3.5x quicker and 2.6x smaller than the XML DataContract serializer; and
5.3x quicker and 1.3x smaller than the JSON DataContract serializer.
Here's a MonoTouch tutorial showing how to call web services from an iPhone:
http://www.servicestack.net/monotouch/remote-info/
IF you are ok with a c++ library in your iPhone projects, then please have a look at yaml-cpp:
http://code.google.com/p/yaml-cpp/
has native iPhone support (via it's cmake build system)
has no dependencies beyond a good compiler and cmake
is very c++ friendly (thus, the name) with solid documentation (see the wiki/HowToParseADocument page)
It really depends on your need and what kind of data you are going to transfer between server and application. If you want to execute queries to select some piece of data you should choose XML because of XQuery language support. JSON is not supported, as I know. I can nothing to say about YAML.
I have not seen any YAML libraries (though it does not mean there are none). I know TouchJSON works pretty well, and there is at least one other.
JSON takes less space than an XML or PLIST feed, BUT needs a little more thinking ahead of time to get the structure right.
One nice aspect of pLists is that you get back dates as objects without parsing. If you pass dates in a JSON decide on a format and use the same format everywhere. NSDateFormatter is not thread safe so you have to make an instance per thread, if you want to use a single date formatter to save resources.
there is support for all three formats in Objective-C. Just google for them. I would suggest writing a serializer that supports all three. Just make your URL resource request end with .xml|.json|.yaml and have the server decided what to serialize to based on that extension. Then you don't actually have to decide you can switch to whatever you want. Making the serializer pluggable is really easy in most server side implementations.
Have you ever seen a good reason to create a custom binary rest protocol instead of using the basic http rest implementation?
I am currently working on a service oriented architecture framework in .Net responsible for hosting and consuming services. I don't want to be based on an existing framework like Remoting or WCF, because I want total flexibility and control for performing custom optimization.
So here I am trying to find the best protocol for handling this SOA framework. I like the request/response stateless connection nature of REST and the uri for defining resources, but I dislike the text based nature of HTTP.
Here are my arguments for disliking HTTP, correct me if I'm wrong:
First an evidence, parsing text is less efficient than parsing binary.
I'd prefer a fixed length binary header containing the content length and a binary content.
Second, there is no notion of sequence number for http requests, so the only way of associating a response with its request is the socket connection used to send the request and receiving the response.
This means there can only be one pending request at a time for a specified socket, so if a service consumer want to send multiple requests in parallel to a service, it need to open multiple socket to the server.
A custom rest protocol could define a sequence number for requests, so request and response would be associated with the sequence number instead of the socket and there could be multiple requests sent in parallel on the same socket.
I think there is no way to do this standardly with HTTP, it could be done with a custom text based protocol, but why not make it binary based to gain performance.
To add a little more context, my SOA framework does not need to be accessible from a non .Net consumer, so I have no restriction about using the .Net binary formatter or another custom binary formatter.
So am I making any sense for wanting a custom binary rest protocol? If you think I'm wrong please tell me your arguments.
Thanks.
REST is an architectural style for constructing web services. Roy Fielding articulated it based on his experience in designing HTTP, but it transcends HTTP. You can deploy a RESTful service over ordinary email exchange for instance.
The REST representations of your resources can be anything you like, though Roy really stresses that people should try to use very carefully designed, standard representations. There's nothing wrong with binary. In fact image representations like JPEG and PNG are binary. Google's Protocol Buffers gives you ways of creating compact binary representations of structured data too.
So the short answer is that you can certainly be RESTful and use binary representations and a home-grown binary substitute for HTTP.
I would actually very strongly recommend you use HTTP for efficiency, though. If you use your own protocol then you lose all the leverage provided by the wonderful HTTP caching infrastructure that stands between your server and its clients. The full client load falls right on your server instead of getting spread out over the intermediate caches.
10/4/2010: In our HTTP-based REST APIs we now support Java Serialized Object and Kryo binary representations in addition to XML, JSON, and XHTML. The Kryo serialization library performs significantly better than the others without requiring any special protocol. Another alternative to cut down on bandwidth is to use HTTP compression along with a textual representation.
The data of your packets can be whatever you like; be it XML, Plaintext, JSON, or just a binary format. I see no reason to force any specific one of these on yourself (use whatever is most fitting).
Though, when saying 'binary format', most people hear a fixed format of field-lengths and other really annoying things. Generally, if you aren't desperate from a data-transfer point of view, I see no reason to go this way [though you may do a binary serialisation of .net objects so they can be re-instantiated [or look at the 'protocol buffers' lib for .net]].
Summary: Seems okay to me. Whatever floats your boat.
Have you ever seen a good reason to create a custom binary rest protocol instead of using the basic http rest implementation?
I'm not sure I understand your terms. A REST representation can be completely binary, and still transported over pure HTTP. There's no need to invent a new protocol just to transmit binary data. Just reduce your requirements to a well-documented media type (which you're free to invent).
Regarding binary resource representations, Fielding himself argues that binary is not only acceptable, but may be required in some situations.
Regardless of whether you go straight binary, Base64 mixed with text, or text-only, don't forget the hypertext constraint if you plan on calling what you do "REST".
So am I making any sense for wanting a custom binary rest protocol?
If you mean you'd like to create a custom, binary-only, hypertext-driven media type - that's perfectly reasonable.
If you're talking about inventing some custom extension to HTTP, I would avoid that unless absolutely necessary (and what you describe doesn't sound to me like it rises to that level).
I want total flexibility and control
Based in this statement then I would suggest one of two choices. Either straight TCP/IP sockets, or WCF. These options give you by far the most flexibility. WCF is a great solution if you want to be transport agnostic and you want to start with a clean state as far as an application protocol is concerned.
REST imposes a set of constraints that restrict how your distributed application behaves in order to gain certain beneficial characteristics. If you see your service end points as ways to invoke operations then I suggest that REST will not fit your needs well at all.
Somehow, I don't think whether you send binary or text payloads should be your biggest concern at this point.