Android support for V2 tokens
Closed this issue · 15 comments
What are the plans for Android support?
It looks like it should be fairly easy to make the V2 tokens compatible for Android using lazysodium-android. It's also stated in the README that GSON will be supported in the future which would make compatibility easier.
Hey,
I had thought about adding Android support initially but couldn't think of a use case. It should be simple to add another v2 crypto provider which uses lazysodium-android. I'll take a look, as I suspect it should be nearly identical to the already existing lazysodium provider. I suspect v1 will already work on Android.
As for GSON support, it should be pretty easy to add. I have always intended to add support for GSON, just haven't had a reason to look into it yet.
I've opened a pull request with our changes (#4).
These changes work fine when importing the code directly into an Android application, but I haven't achieved to make an Android library out of it.
I also started working on this by making a new v2 crypto provider for Android. There are other issues though, as I had initially wrote this library to support only JDK8+, which means that on Android it will only work with API level 26 or higher. I don't want to just replace the standard LazySodium with the Android variant as that will likely break support outside of Android.
If support for lower API levels are needed (and it probably should be), then at least these changes will be required:
- Add a way to override the Base64 implementation used internally, as right now the library is using the Base64 support including with Java 8. I already had this, but removed it as the rest of the library requires Java 8 as well. This is pretty easy to solve.
- The higher level API currently uses the new Java 8 Date/Time classes. These classes also require API level 26 on Android. I could switch to ThreeTenBP, but that will make usage awkward in any project which actually uses Java 8, which is the primary focus the project. I guess I could split the higher level api off into it's own jar, and provide an alternative which uses ThreeTenBP for Java 7 support.
- The Jackson encoder is also dependent upon the Java 8 time APIs so that it can (de)serialize dates & times. This will also be a requirement for the future GSON encoder.
As it stands right now I have the low level Paseto API working on API level 17 with the Base64 change and the Android v2 crypto provider. On API level 26 everything should work, although I've only done minimal testing.
I'm going to work on adding GSON and cleaning it up a little then I'll push out a new release.
Yes, this could be implemented as PasetoAndroid and PasetoJava extending the Paseto interface, like Lazy Sodium is doing.
(Note that PasetoJava could also be used from Clojure, which I have been able to do without problems.)
Seconded. @atholbro are you going to implement this? Android Support would be great!
Yes! I do intend on getting back to this.
Hey all,
Lazysodium maintainer here. I really like the work you're doing here. Let me know if you need help with this 👍
PS: If you want, you can use jCenter() as a remote repository rather than our maven { url "https://dl.bintray.com/terl/lazysodium-maven" }. Most developers already include jCenter() into their projects so could be easier for developers to integrate into their projects. However, jCenter() does sync slower than our own Bintray repository which can be a big disadvantage for some projects.
@gurpreet- You might want to provide interfaces for the AEAD functions that don’t need the nonce, as this argument will apparently be dropped from libsodium: jedisct1/swift-sodium#173
We have had some confusion between the KeyPair/Key classes of LazySodium and the KeyPair class of PASETO, but other than that it has been pretty much smooth sailing.
What was the issue/confusion you ran into with the KeyPair/Key classes? Maybe I can tweak the README to clear it up.
I don’t think it needs any explanation, it’s just that your PASETO library could use the KeyPair class from LazySodium instead of having another very similar implementation.
Still planning to do this, just been busy.
I'm leaning towards using 310BP internally and changing the Token class to return times as a unix timestamp (long) rather then an OffsetDateTime. Otherwise I'd either need to expose 310BP, which would make interfacing with any java 8 code annoying as you'd have to convert from JSR310 to 310BP (which would be similar to dealing with the timestamps). Or I'd have to split the library even more to have JSR310 and 310BP versions, which was my initial idea but it would also require splitting the json encoders as well, which just ends up becoming crazy when we add GSON into the mix.
Changing the Token class to use unix timestamps would be a great solution.
Would you then have the deserialiser take a formatted string and convert it to unix timestamps?
I'm playing around with this idea in the threeten-abstract branch. It goes a bit further by creating some small abstraction classes around the few Java 8 Time API features the library uses. There are two implementations of these abstractions, one using JSR310 and another using ThreeTenBP. By changing which dependency is imported via gradle, the library can now be switched to work with either JSR310 or ThreeTenBP without further code changes.
The public interfaces now expose times as unix timestamps stored in Longs. The JSON serializer/deserializer now uses these internal abstraction classes, and seamlessly switches between JSR310 / ThreeTenBP without code changes.
Essentially you can now swap between JSR310 / ThreeTenBP by changing the gradle dependency. The meta project pulls in the JSR310 variant, but I can provide a 'paseto-java7' library which pulls in the ThreeTenBP variant. The selecting between the two is just a matter of which you library you use.
I have this mostly working.
V2 public tokens aren't working on Android yet, due to what seems like a bug in LazySodium-Android. I've opened an issue, and when its fixed Android support should be ready for release.
I finally finished this, the new Android support is contained in a new repository:
https://github.com/atholbro/paseto-android/tree/master
The API is exactly the same as Java, the only 2 changes from the user's point of view are:
- Use the Android dependencies.
- Setup ThreeTen-ABP if you're not already using it (one line of code in your Application class).