What are authentication options for Phoenix/Absinthe

Phoenix Forum Questions / Help
, ,
1

I read through some of the forum posts, and it looks like we might want to update this conversation.

I have built several personal (toy) apps in Phoenix. It now looks like I might be able to pitch a new project using Phoenix. We have used Rails for our MVC projects for the past ten years, but we’re looking to edit our workflow a bit. We are looking to do the following:

  • Create Phoenix/Absinthe as an API for all data
  • Create a separate Phoenix app for the application interface.
  • Create some Authentication/Authorization system that the front end application can use with the API.

In the past, we’ve used Rails/Devise for authentication (and the ability to change passwords, etc.). Still, one of our primary goals is to remove the Authentication system from the application.

How are you guys doing this for professional (and relatively high traffic) applications?

Thanks!

1 Like
2

APIs are very hard to properly secure(I work in a company specialized in tackling the issue), therefore unless you have a strong use case for exposing an API, don’t do it.

Instead just write your code were business logic is totally separated from the web app logic, thus if in the future you need to add a mobile app then it’s very easy to build an API for it.

I strongly advise you to build your web app in the traditional way, aka without using APIs, and by preference with the LiveView approach, that creates more strong ties between the backend and the client side.

Just build an Authentication server that works through the powerful message passing mechanism that Elixir provides, and then use it as a path dependency to any of your projects in order to use it as a BEAM node in your application, but not exposing it as an API to the Internet. This is my 2 cents high level view, and I don’t have production experience yet with Elixir, but this how I am gonna build it for all the web apps I am planning to put online.

2 Likes
3

This sounds like good advice. honestly, the reason we were talking about using an API was solely for proof of concept. I will probably be asking more questions about authentication in the future.

We discussed our options this morning, and we’re beginning work on this solution today.

Thanks!

1 Like
4

I worked previously in an agency as a backend developer for mobile APIs to support mobile apps of big retailers and I was a huge advocate of building one good API with OpenAPI specs, and then use it all over the place for web apps ans mobile apps, but when I changed to work in mobile API security I totally changed my opinion, and now I just advocate for building an API when you really need it, and more often then not you don’t need one for a web app, and in the Elixir world this is even more true :wink:

5

strictly because

?

Aren’t there non-negligible pros like JAMstack where SPAs on CDNs scale much easier than LiveView?

6

I will not discuss scalability, because what I was discussing is security.

In my opinion security should be a first class citizen in any software project, but unfortunately in 2021 is still an afterthought, and this all come down how to developers not being properly educated from the begin of their career at treating security as an opt-out, instead of the current approach of opt-in.

The business side of the company doesn’t help too in this process, because they only take security seriously when they are hacked, when they need to be compliant with some standards to be able to do business or when some law specifically requires some measures, but even here they just do enough to tick the compliance or law boxes, and daily hackers prove that that attitude is not enough.

So, I work in API security daily and my newsletter subscriptions are full of data-breaches, exploits, OWASP failures, and etc, etc, and the majority of developers don’t have 10% idea of how bad things are, as I wasn’t until I got to work in this space.

It’s important for a developer to understand the difference between who and what is accessing an APIi in order to be able to change it’s security posture about software developement. Read more in this article I wrote:

The who is the user of the mobile app that we can authenticate, authorize and identify in several ways, like using OpenID Connect or OAUTH2 flows.

Now we need a way to identify what is calling your API server, and here things become more tricky than most developers may think. The what is the thing making the request to the API server. Is it really a genuine instance of your mobile app, or is a bot, an automated script or an attacker manually poking around your API server with a tool like Postman?

By the way being OWASP compliant is not enough to secure your APIs and if you want I can give you reading on it.

2 Likes
7

JAMstack technology only makes the easily scalable part even easier to scale. It is a benefit for sure, but not as big as people would like to believe.

3 Likes
8

Fully agree with you. I occasionally see people are still using password storage-wise insecure hashing algorithms, such as SHA-2 and even SHA-1. Really frustrating we software developers couldn’t constitute a good foundation in time, for such simple problems.

I think this emanates from companies having nearly zero obligations on storing customer data, the penalties are yet fractions of the amounts that the companies will be unwilling to pay.

Just my two cents here, I would also consider using authentication gateways for APIs, such as Ambassador (particularly when using Kubernetes) and Kong (mild hybrid solution). They are pretty straightforward to get up and running, integrations with social media and OAuth systems are simple as a breath. Definitely good value there.

9

Please share the reading material for learning thanks.

SPA’s are also a bad idea then I suppose ? Similar to mobile they work with APIs

1 Like
10

Good point, but playing devil’s advocate here, wouldn’t tightly coupling your front+backend (e.g. LiveView monolith as is suggested) propagate backend scalability challenges to your view layer?

11
  • you still can offload static asset serving to a CDN with liveview
  • you can scale out the old fashion way, just throw more hardware at it
  • thinking about scalability too early is counter-productive.
1 Like
12

In all answers I gave in StackOverflow I normally end-up the answer with some links to the OWASP material:

Do You Want To Go The Extra Mile?

In any response to a security question I always like to reference the excellent work from the OWASP foundation.

For APIS

OWASP API Security Top 10

The OWASP API Security Project seeks to provide value to software developers and security assessors by underscoring the potential risks in insecure APIs, and illustrating how these risks may be mitigated. In order to facilitate this goal, the OWASP API Security Project will create and maintain a Top 10 API Security Risks document, as well as a documentation portal for best practices when creating or assessing APIs.

For Mobile Apps

OWASP Mobile Security Project - Top 10 risks

The OWASP Mobile Security Project is a centralized resource intended to give developers and security teams the resources they need to build and maintain secure mobile applications. Through the project, our goal is to classify mobile security risks and provide developmental controls to reduce their impact or likelihood of exploitation.

OWASP - Mobile Security Testing Guide:

The Mobile Security Testing Guide (MSTG) is a comprehensive manual for mobile app security development, testing and reverse engineering.

For Web Apps

The Web Security Testing Guide:

The OWASP Web Security Testing Guide includes a “best practice” penetration testing framework which users can implement in their own organizations and a “low level” penetration testing guide that describes techniques for testing most common web application and web service security issues.

Now, if your app takes in account all OWASP top ten risks you are only protecting it from being exploited through vulnerabilities, but you are not protecting it from being exploited through impersonation or if you prefer spoofed requests. My CEO makes these points in this video and article on the context of a mobile API, but the main points are still valid for any API. I need to do a disclaimer, the video contains a pitch to our product, but I think its still useful to better help you understand why it’s important that you go behind OWASP TOP 10 to ensure that your API is not exploitable via spoofed requests, aka to identify that the request is indeed from what you expect, your original and untampered app.

You can also read more about protecting APIs in the several answers I gave in StackOverflow, like:

1 Like
13

SPA’s it’s not the traditional way to build web apps, unless you never knew other way of doing it :wink:

APIs are excellent way to make a business move forwarded quickly in this digital era, and in the web SPA’s are usually the way chosen to do it, but it comes at a very high price, because data is now more easily extracted by Hackers, and the weekly news confirm that. Take for example the Open Banking API initiative to bring banks to the new era, it allows to build amazing decoupled products, but its costing a lot of money to the banks due to fraud they are not able to block from being committed through the APIs.

The point is, if your API is valuable for an attacker, be it financially or in terms of data, he will find the way to impersonate your genuine apps. Nowadays they don’t even try that hard to identify OWASP top 10 vulnerabilities to exploit, because often it’s more easy for them to observe how the app communicates with the backend and then build scripts to replicate the human behavior.

14

Okay but how is an official banking app (made by the same bank) supposed to communicate with the bank’s backend then?

2 Likes
15

Interested, could you elaborate on this ? What happens to templates?

16

I was talking about the images, css and js.

1 Like
17

So, the main point of all this discussion is that you shouldn’t use an API for a web app just because you can. For mobile apps you almost don’t have other choice then going with the API, be it a REST API or a GraphQL one.

In the context of web-apps the old school ones are not using API’s and are tied up directly to their backend via the usual session cookies. While this ties up more the client to the server, specially when advanced fingerprint techniques are used, they still need to use User Behaviour Analytics in the backend, because the web app is still volatile to impersonation, just not so easy to achieve as when the web app is using APIs.

For mobile apps they usually use the traditionally APIs, with in house specs, but now they need to follow the Open Banking API specification. These API backends require even more advanced protections, because it’s extremely hard to differentiate what is doing the request.

If you want to feel how much easier is to impersonate an API vs a backend for a Web app, just try to figure out a webapp that doesn’t talk with an API, like easyjet(at least in the past wasn’t), and then try the same with one that uses an API, and you will see how usually it’s much easier to impersonate the one speaking the API idiom.

1 Like
18

Ah. We agree on that. When it comes to web apps and when I am given the power to decide I’ll prefer to make server-side rendered app for both security and engineering reasons.

1 Like
19

We made a bunch of APIs with my team, exchanging JSON but using traditional login and sessien cookies. So it’s not actually REST but it is simple. Is that OK according to you @Exadra37 ? I guess a mobile app could do the same. What is the difference between a cookie (traditional web app) and another header? I don’t get the difference, security-wise.

20

I recommend you to read the Mozilla guide:

There are a couple of ways to ensure that cookies are sent securely and are not accessed by unintended parties or scripts: the Secure attribute and the HttpOnly attribute.

The httpOnly flag is not the only one that should be in use, but some of the flags only have meaning when used in the context of a browser in order to prevent Javascript on that page to steal the cookies. Off-course you can always hit F12 and steel the cookie manually to use in a script, and thats why sites like banks and others used advanced fingerprint techniques within the cookie.

Other headers, like api-key, are so easy to extract by Javascript and reuse in another script and your API server will not be able to tell the difference regarding what is doing the request.

1 Like