Проблем

Претпоставимо да је потребно креирати API сервис за мобилну апликацију, при чему апликација мора да буде потпуно функционална без тражења од корисника да се (првобитно) региструју. Разлога може да буде више, на примјер:

• Апликација само преузима неки садржај, и нема очигледне користи од регистрације ни за нас ни за кориснике
• Многе потенцијалне кориснике може да одбије захтјев за регистрацијом
• Креирање логовања преко социјалних мрежа или регистрације са имејлом и шифром је напорно
• Брину нас стриктни GDPR прописи и радије не би да имамо приступ приватним подацима ако за њима нема потребе

Али, и даље желимо да наши API сервиси буду екслузивни за нашу апликацију, како би спријечили злоупотребу података, али и ресурса за које плаћамо.

Може се наићи на неколико опција, али су све проблематичне:

1. Потпуно отворен API - За ово смо се већ изјаснили да није опција
2. Кориштење тајног кључа, дијељеног између апликације и сервера - Ово је лако провалити, јер се апликације релативно лако декомпајлирају, а текстуалне константе извлаче без проблема. У случају да се кључ открије, потребно је ажурирати и апликацију и сервер, и функционисаће све док се и нови кључ не открије на потпуно исти начин
3. Спремање дијелова кључа на различита мјеста у коду, или кориштење релативно једноставног алгоритма за његово генерисање - Ово није знатно теже за провалити од претходног случаја, тако да подједнако није вриједно труда

Међутим, све и да тражимо од корисника да се региструју, неко ко је довољно способан да открије свој легитимно добијени приступни кључ према API сервисима, и даље може да их злоупотријеби уколико не постоји механизам за ограничавање њиховог кориштења, попут ограничавања и пригушивања броја захтјева. Можемо поставити ограничења на бази ИП адреса (и то је увијек потребно!), али то ограничење се лако заобиђе кориштењем различитих прокси сервера, или са могућношћу приступа већем броју уређаја са конекцијом на интернет и са различитим ИП адресама.

Рјешење

Дакле, и даље нам је потребан некакав вид регистрације. Али, умјесто корисника, можемо да региструјемо уређај. Међутим, како ћемо да знамо да је управо наша апликација та која жели да се региструје, а не неко или нешто друго? Тако што ћемо да искористимо нешто што је јединствено за нашу апликацију, а то су пуш нотификације.

Одрицање од одговорности: не постоје рјешења која су непробојна, а самим тим ни ово није једно од њих. Међутим, довољно је добро да држи подаље оне који су мање технички спретни или мање мотивисани, а уједно и омогућује примјену сигурносних стратегија сличних онима гдје постоје регистровани корисници.

Без даљег дужења, слиједи потпуни дијаграм секвенци процеса регистрације уређаја:

Укратко речено: апликација тражи од сервера да јој пошаље УРЛ за регистрацију преко податковне пуш поруке, који је уједно енкриптован јавним кључем који је генерисала апликација.

Након што је регистрација завршена, наредне аутентикације уређаја на API могу да се обављају стандардним освјежавањем токена.

Важне напомене у вези изазова за регистрацију:

• Рок да се испуни неки изазов треба да буде релативно кратак, не дужи од пар минута
• Серверске руте за захтјевање и испуњавање изазова су јавне, и приступ њима треба да буде што боље ограничен
• Потребно је имплементирати некакав процес у позадини који ће да брише све изазове из базе чији је рок истекао (или постављањем TTL вриједности ако се користи нпр. Redis)

Генерисани ЈИБ уређаја може да буде UUID или нешто слично. А ако је достављање пуш нотификација саставни дио апликације, онда би било добро негдје сачувати ЈИБ заједно са регистрационим токеном пуш сервиса (и тако ефективно направити налог за уређај), како би се регистрациони токен лако ажурирао на серверу након што мобилна апликација добије нови токен од пуш сервиса. Важно је напоменути да није потребно одобрење од корисника апликације за добијање податковних порука уколико оне не садрже нотификације.

Чувајући ЈИБ уређаја унутар приступног токена и токена за освјежавање нам омогућава да ограничимо кориштење сервиса по уређају, а у случају да је детектовано сумњиво понашање, могуће је и одбити захтјев за освјежењем приступног токена и тако привремено или трајно угасити налог. Зато је потребно да рок трајања приступног токена буде разумно кратак.

Употреба у Стварном Свијету™

Иако имам пројекат који је тзв. доказ концепта овог дизајна, он није још увијек спреман за продукцију. Међутим, ако се некоме свидјела идеја и жели да је примијени у својој апликацији, волио бих да сазнам колико добро је прошла, и о том ме можете обавијестити преко било ког канала на којем сам присутан. Можда немам коментаре на овом сајту, али радо ћу објавити искуства из ”стварног свијета” у оквиру овог чланка, наравно уз одобрење.