Насколько это будет безопасно?

Если соединение защищённое, а id кроме сервера и клиента никто не знает, и он достаточно длинный, чтоб его нельзя было подобрать (т. е. как минимум 12 случайных буквенно-цифровых символов, а лучше — больше, 8 сейчас уже мало), то, имхо, вполне безопасно. Только зачем тогда городить огород с sha256, если соединение и так защищено? А если не защищено, то sha256, переданный открытым текстом — это как пароль, переданный открытым текстом. Мне кажется, как-то так.

Вот хранить вместо id хэш, при условии, что этот id не передаётся, а только принимается, имеет смысл на случай взлома сервера. И лучше при генерации хэша добавлять «соль».

И зачем было текст обрамлять тегами [code]? Сними их, они в данном случае лишние и мешают, потому что текст приходится прокручивать.

Я так понял это типа ssl? Так если https используется зачем эта матрёшка?

Что за поток букв, нельзя было сформулировать мысль прежде чем писать?

На сервере, сервер получает запрос с sha256 хешем, он берёт изветные ему статический id клиента и из базы ещё id делает от них sha256

У клиента есть два id и хэш от них, и у сервера те же два айди и хэш от них. Зачему нужны какие-то айди и хэши? Можно хранить на сервере и клиенте один айди и передавать тупо его, разницы никакой не будет.

далее берёт свой статический id и склеивает с хешем который пришёл и делает от этого ещё sha256 отсылает ответ клиенту

клиент знает статический id сервера он склеивает свой запрос и id сервера делает sha256 от них и сравнивает с ответом сервера

То же самое.

если всё с обеих сторон прошло нормально они уверены что они это они

Ну ок, допустим обмен хэшами прошел нормально, а данные подменили (хэши не трогали). Не вижу связи хэшей с данными, без этого (да, в очередной раз повторяюсь) вы можете обмениваться тупо одной известной строкой.

всё это внутри https

Тогда сервер и клиент и так знают друг друга.

Короче, если вы хотите проверять что данные не поменяли по дороге - хэшируйте их (ну точнее используйте обратимые функции). Если клиент просто должен быть уверен что ответ пришел от вашего сервера - хватит https.

Фактически у тебя туда-сюда передаётся просто токен. Зачем нужны дополнительные телодвижения на клиенте и сервере совершенно не понятно. Вместо всей этой херни проще использовать HTTP Basic Auth, т.к. оно обычно поддерживается из коробки. Клиенту вообще ничего специально не нужно делать, он и так может проверить https-сервер по сертификату.

открой для себя HMAC, ECDSA, JWT.

ну или часто делают так, пусть:

• T - timestamp / nonce
• U - public id - public_api_key
• S - shared secret - private_api_key
• R - request payload

POST

• X-Timestamp: T
• X-Api-Key: U
• X-Api-Signature: HMAC(S, T + U + R)
• R

https можно обойти путём подмены, не раз уже эта тема поднималась, post сообщения подвергаются дополнительному шифрованию, даже в случае если злоумышленник получит расшифрованный https трафик он останется с носом, та как получит ещё один зашифрованный трафик.

За JWT спасибо, не знал, не как основное, но как дополнительное средство авторизации пригодится.