I’ve written the occasional OAuth2 client application over the years but never really understood what was going on with client-ids, secrets, grants, scopes, and so forth. However I’m currently involved in a project to migrate a large IT system to using OAuth2 and OpenID Connect, so it is clearly time to learn this stuff properly.
I’ve finally got around to learning Kotlin, a popular language best known for running on the JVM and competing with Java.
A useful discovery I made recently: if you need a relational database for demo or testing purposes, then Postgres publishes a really convenient official Docker image. What it not immediately clear is that this image has a mechanism for running arbitrary SQL scripts on startup - which is great for defining tables.
It is therefore trivial to create an image that others (eg developers or sales) can quickly deploy, that contains not only a database server but also whatever initial schema you need.
I run my own email-server - and it is rather a complicated business. For those interested, I have recently documented my research on the topic of email validation using SPF, DKIM and DMARC - or in other words, how to block incoming spam and how to avoid having outgoing email be blocked by others.
There has recently been a strong trend towards forcing the use of a modern mobile phone for authenticating to online banking.
I’ve been rather cautious about this, and currently use a dedicated “tan generator” device which my bank reluctantly offers as an alternative. The principal problem I have with using an application on a phone as an authentication mechanism is:
a phone typically has many other apps installed on it, and
phone operating systems have security holes (eg android and iphone)
However it appears that things are improving in this area, at least with the Android mobile OS: Android’s Trusted Execution Environment, Strongbox API, and phones with embedded security chips (eg Google’s Pixel3) make rogue apps (even with root-level access) far less of a problem.